Marc Lehmann writes:
> > - 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 ;)
gtk-config (or glib-config) is not a problem for people who *build*
glib and/or gtk+ themselves, they know where they are going to install
it, and they could generate a suitable *-config script. The problem is
producing a glib-config or gtk-config for people who download the
headers and prebuilt libs (in a zipfile), and install them in some
random place, and then would like to build some application.
> This is, of course, not solvable in any case. Changing the compiler means
> that all the autodetected stuff goes wrong.
It isn't necessarily that bad, remember that mingw and MSVC use the
same runtime, and all header files that are present in MSVC have
clones in mingw. Most autodetected stuff is equally valid for mingw
and MSVC. (One difference is that gcc uses long long and the LL suffix
for long long literals, MSVC uses __int64 and the i64 suffix. The
corresponding printf format is obviously the same, though, as the C
library is the same.)
> This also means that the compiler used to build gtk+, gimp,
> gtk-perl and gimp-perl must be the same.
Wrong. Nothing prevents mixing MSVC- and gcc-compiled DLLs and EXEs of
GLib, GTK+. I don't think Gtk-Perl or Gimp-Perl should need to care
either.
> 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).
On Win32, the mingw gcc *is* compatible with MSVC (for C; C++ is
another matter). The bleeding edge of binutils (which I personally
don't use yet) can even link to DLLs directly (autogenerating import
libraries on the fly), or use libraries in MS's format.
> The better option IMHO would be to make glib (source available!)
> compilable against perl, as a compatibility measure on win32.
Yes, the dirent emulation is GLib has caused some problems before, as
it isn't the same emulation as that in the libmingw32 library (which
the mingw gcc automatically links with).
I will probably move the dirent stuff out to a separate library (so
that it is available for MSVC users), and make it identical to the one
in libmingw32.
(I think it was wrong to include dirent emulation in libmingw32, and a
<dirent.h> header, as that breaks being able to compile the same code
with either gcc or MSVC.)
> Certainly. Also not concentrating on gtk-perl but instead on gimp-perl
> would also help.
I haven't looked at Gimp-Perl yet, I kinda assumed a working Gtk-Perl
is a prerequisite.
> OTOH, the main gimp makefile also uses test and a lot of unix-things. Is
> gimp not build using autoconf on win32?
Nope. This most likely will change at some point when I have the time
to look into it. One problem I can think of right now is that the gimp
modules want to use entry points in the gimp executable, and for that
to work on Win32 you must mark those entry points for export when
building the exe. I.e. build the exe kinda like you would build a DLL.
There is no mechanism in auto* or libtool to handle that, I think.
It now seems as it indeed would be easier to use a Perl running on
cygwin to produce the Makefiles for Gtk-Perl and Gimp-Perl (Makefiles
for GNU Make and a cygwin shell), but still have those Makefiles run
the mingw gcc. (That's the kind of Makefiles I build GLib, GTK+ and
GIMP with.)
--tml
