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 (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

- 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

- 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...)


Reply via email to