[Note: I CC:'ied this as well as tor's original mail to the current gtk
maintainer, which is Paolo Molaro <lupus@xxxxxxxxxx>]
On Fri, Jan 05, 2001 at 01:33:42AM +0200, Tor Lillqvist <tml@xxxxxx> wrote:
> 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
Certainly there are different grades of difficulty. I'd choose a
cygwin-ported perl, as the makefile that _that_ perl generates can be very
unix-like (gnu-make) and calling the shell is no problem, either.
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.
> - 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!.
> - 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).
> #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
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.
> Maybe it would be better to use a Perl running on cygwin? That would
> help a couple of the issues above.
Certainly. Also not concentrating on gtk-perl but instead on gimp-perl
would also help.
During the run for gimp-1.2 I introduced a lot of unix-things (like
"test2) in gimp-perls makefile, but these are mostly limited to
installation (Especially po, which is not a concern for the gimp
distribution).
OTOH, the main gimp makefile also uses test and a lot of unix-things. Is
gimp not build using autoconf on win32?
> 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
There was, however, I am quite sure nobody ever tried to port it to
win32. At least not to a non-unix-like target (mingw32 or msvc).
> (I am not promising that I will hack any more on Gtk-Perl on Win32
> anytime soon...)
This is fine ;) Even trying to build and fail (and you did more) should
be very helpful to them I think. Just as I would expect that somebody who
tried to build gimp-perl on win32 would end up saying "it bails out during
Makefile.PL because it calls ./configure", and I would be happy with that
;)
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
