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 <[EMAIL PROTECTED]>]
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
--
-----------------------------------------------------------------
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better
