Hi
I usually try to avoid playing with GNUstep on Windows as it always
takes too long to setup an environment to run stuff in, but these
pkg-config discussions drew me back in.
Wim Oudshoorn schrieb:
Well, did you actually try compiling pkg-config?
I did not investigate deeply but the suggested way of compiling:
./configure
make
Did not work. ./configure succeeded splendidly, but make
failed and the reason was that glib.h could not be found.
But I don't want to start a discussion in the GNUstep mailing lists on
how to install pkg-config. I just wanted to see how it would work on windows.
I wanted to keep out of this discussion, but somehow these resolutions
never work out :-)
First of all there is a pre-compiled pkg-config for Windows on the Gimp
download page, but be warned, I have not used it myself:
http://www.gimp.org/~tml/gimp/win32/pkg-config-0.20.zip
I started by trying to compile the glib included with pkg-config on
Windows...this failed to work properly. I then tried to download the
source code for glib 2.0 on Windows. Quite annoyingly, glib 2.0 depends
on pkg-config, and pkg-config depends on glib, which leads to a
ridiculous chicken-and-egg situation. I gave up trying to compile either
of them and downloaded the binaries from gimp.org.
They seem to work correctly, although I was struggling with the
pkg-config files that come with all the gnuwin32 stuff (i.e. all those
precompiled dependencies such as zlib, libjpeg, libtiff, libpng, etc).
This is because as pkg-config hardcodes paths in its .pc files, and the
.pc files distributed with gnuwin32 binaries pathnames to directories on
the machines they were compiled on e.g. c:/progra~1/libiconv. Hopefully
things like this can be cleaned up with a sed script.
Second, I like the idea of using more standard tools in the GNUstep
configuration and compilation process. pkg-config could come in rather
nicely here. But I don't quite understand, how it could be used as a
replacement for GNUstep.conf. Not that I like the role GNUstep.conf is
currently playing in GNUstep, but this is clearly different from what
pkg-config is normally doing. GNUstep.conf is a file that gets accessed
each time a GNUstep application is run to find out about the various
GNUstep settings. It is there to allow GNUstep installations to be moved
to arbitrary places after compilation. pkf-config is by its intention a
compile time tool. It looks for include paths and libraries and such
stuff. It is not supposed to be around when a compiled application or
libraries is run.
Considering some of the effort needed to get pkg-config working on
Windows, could we please maintain all existing build methods in
gnustep-make? IMHO pkg-config still feels like a alpha quality programme
in some environments, despite being widely used. The classic
gnustep-make build environment is still my first choice and is alot
easier to install as it has no unusual or difficult dependencies.
Lastly, on a slightly unrelated note, the GNU dependencies (zlib,
libpng, libjpeg, etc) that are needed to compile GNUstep on Windows can
be automated using an installer from the gnuwin32.sf.net project which
downloads most of the precompiled GNU environment. I was thinking that
it may be possible to take the scripts given there, combine them with
scripts for installing mingw/msys and create an installable mingw
environment on Windows that is ready to compile source code within.