On 01/05/01 Marc Lehmann wrote: > [Note: I CC:'ied this as well as tor's original mail to the current gtk > maintainer, which is Paolo Molaro <lupus@xxxxxxxxxx>] I didn't get the original mail from Tori, but I got it from the archive anyway... > The most difficult one would indeed be activestate (the dominant perl), > since activestate is ported closely to windows (it is the "better" port in > that sense) and all of the extension problems (e.g.) get real, although > the makefiles that perl itself generates should be fine. Using the same compiler for perl, gtk+ and gtk/perl is the first step to narrow down the possible compilation problems.... > > - 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 > > The same, of course, is true for the gimp. most people who build gimp > would be able to build gtk as well ;) > > In any case, gtk-perl does, indeed, use a lot of unix functionality so > building that one without cygwin will require !CHANGES!. Yep, cygwin should be the easiest route, though I don't know if it has other issues (I don't use windows and don't plan to to try it out:-). That said, I'll integrate the patches needed to make it work, just make them against cvs HEAD (module gnome-perl in the gnome cvs). > > - 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. > > This is, of course, not solvable in any case. Changing the compiler means > that all the autodetected stuff goes wrong. This also means that the > compiler used to build gtk+, gimp, gtk-perl and gimp-perl must be the > same. We have a lot of problems with this (obvious for me but not others > it seems), e.g. on IRIX where the preinstalled perl is compiled with the > commercial sgi compiler but most people only have access to gcc (which is > not compatible). Most of the command line options and command names can be changed using makefile variables, but it's a pain neverless. > > #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. > > The better option IMHO would be to make glib (source available!) > compilable against perl, as a compatibility measure on win32. I am not Seconded: maybe check if perl on win32 includes a #define for opendir or something like that and conditionally #define the symbols in glib.h. > sure qwether sources for activestate's port are available and even if, it > requires a non-free compiler. > > > - 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? > > If you have patches, I am quite sure the gtk-perl people will be very > intereste din them, even if they only partially solve the problem by > making it compile for example. Yep, please send me the patches you have. I have been requested several times about gtk-perl for windows, but no one ever sends patches:-) I don't use windows, but I'd love gtk-perl working on win32! > > (I am not promising that I will hack any more on Gtk-Perl on Win32 > > anytime soon...) Every step brings us closer to the target:-) Please do contribute your changes so that someone else doesn't have to redo them if you don't have time to continue working on it. Thanks! lupus -- ----------------------------------------------------------------- lupus@xxxxxxxxxx debian/rules lupus@xxxxxxxxxxxxx Monkeys do it better
