Tor Lillqvist writes:
> When I tried (must have been a year ago, I think) the first hurdle
> was porting the Gtk Perl module. As I don't know much about
> building Perl modules on Win32, I gave up.
> I could try again...
Well, I spent a few hours on it yesterday, and some more again today,
but it does seem quite hard, or at least tedious. There are several
hickups... will try to list some:
- What Perl to use? I decided to go the easy way, and use
ActiveState's prebuilt one. Let's see where that takes us.
- Makefile.PL wants to use gtk-config. No such on Win32. (How could
there be one? On Win32, people typically don't build GTK+
themselves, but fetch the headers and libraries, and just unzips
them in some suitable location. Compare to Unix, where people (or
their sysadmins) either configure GTK+ themselves, and thus decide
where it will be installed, or use prebuilt package that drops stuff
into fixed locations. Of course, I could start requiring that the
headers and import libs are placed in a fixed location
(C:\gnu\include, C:\gnu\lib for instance.)
Anyway, even if one hacks a suitable gtk-config shell script, it
will be called from a Perl running on pure Windows, and
system('gtk-config --libs') won't work (there is nothing to
recognise that the (extension-less) gtk-config file somewhere in
PATH is executable, and needs interpretation by a shell), and one
thus needs a wrapper .bat file, or even an .exe, to start a (cygwin)
bash or sh to actually interpret the gtk-config shell
script. Hmm. Some issues passing parameters to the shell script
through the command.com (or cmd.exe) -interpreted .bat file.
- While hacking that gtk-config script, for completeness's sake add a
--toolset option to choose between mingw (gcc) and MSVC (cl). They
both understand the same syntax for -I switches, but for libs, gcc
uses the normal Unix-like -LX:/xxx/xxx -lxxx, while cl wants just
the .lib file names X:/xxx/xxx/xxx.lib .
- ActiveState's Perl is built with MSVC. Its MakeMaker thus produces a
Makefile for nmake, that uses cl to compile and link to link. Oh
well, that is not so bad in itself, I have MSVC available at work,
and, ehh, I might have a copy at home also.
- However the Makefile.PL in Gtk-Perl assumes that the Makefile will
be run on a Unix-like system, and needs some tweaking. Oh well, not
anything impossible, change to use $^X, $Config{obj_ext},
$Config{exe_ext) etc as appropriate. Also change not to generate
Unix shell -specific commands (test -f ... && ...). Also, the
command line syntax for cl is not Unix-like, no -o outputfile
switch.
- Glib on Win32 has an emulation for the dirent functions, defines the
DIR struct, and #defines opendir etc to g_win32_opendir etc. Perl
has its own emulation for these. Hmm. To avoid clashes will have to
include <glib.h> early in the Gtk-Perl .xs files, do some ugly
#defines and stuff to hide the GLib versions. Unfortunately there
are lots of those .xs files that need to have the same stuff
inserted. Oh well, just manual work.
- GdkTypes.h in Gtk-Perl clashes with gdktypes.h in GTK+.
(Case-insensitive filenames.) Have to rename it to GdkTypesPerl.h,
for instance. Rename also GtkTypes.h to GtkTypesPerl.h for stylistic
reasons.
- Some X11-backend specific stuff present in Gtk-Perl. Have to #ifdef
those out, but in a way that is still compatible with GTK+ 1.2,
which didn't have several backends, and doesn't define
GDK_WINDOWING_X11. Gtk-Perl also uses some GDK functions that don't
exist any longer.
At this point I bailed out again... I have better things to do, like,
eh, sleep?
Maybe it would be better to use a Perl running on cygwin? That would
help a couple of the issues above.
Before going any further I should probably contact the Gtk-Perl author
and make sure I am not duplicating somebody else's work in progress,
and to ask if he has done any more work on Gtk-Perl since 0.6123. (This
message is Cc:ed to him.)
(I am not promising that I will hack any more on Gtk-Perl on Win32
anytime soon...)
--tml
