pkg-config/README.win32
Arch Librarian 6fe682ad4f 2001-10-21 Tor Lillqvist <tml@iki.fi>
Author: tml
Date: 2001-10-21 18:40:38 GMT
2001-10-21  Tor Lillqvist  <tml@iki.fi>

	* Makefile.am (EXTRA_DIST): Distribute README.win32.

	* README.win32: Describe the behaviour in more detail.
2005-07-14 13:04:34 +00:00

47 lines
2.6 KiB
Text

pkg-config on Win32
===================
This file describes pkg-config for "pure" Win32. (With Cygwin,
pkg-config 0.8.0 builds fine right out of the box. Cygwin is just
another Unix variant, as far as pkg-config is concerned.) I hesitate
to call this "pure" Win32 target mingw, as the ideal would be for
pkg-config to be usable also by MSVC users. This will require the
addition of an option to print out the flags in the form used by MSVC,
however, which isn't done yet. Anyway, libraries like GLib, Pango, GTK
that are described by pkgconfig files definitely are supposed to be
usable both for MSVC users and gcc ("mingw") users.
There should be no compile-time paths built into the executable of
pkg-config. Likewise, not in the libraries it describes either.
pkg-config uses one optional entry in the Registry: The path to the
pkgconfig installation prefix. (This can be either user-specific (in
HKEY_CURRENT_USER) or for the whole machine (in HKEY_LOCAL_MACHINE).)
If pkg-config.exe is invoked from the "bin" subdirectory of a
directory with a lib/pkgconfig subdirectory, no Registry entry is even
needed, as pkgconfig (actually, the
g_win32_get_package_installation_directory() function in GLib) figures
out the directory by itself.
When pkg-config is invoked on Windows, it sets the "prefix" variable
to pkg-config's own installation prefix. (I.e. the same installation
prefix that it uses when determining where to find the pkgconfig
directory.) Thus, if an end-user (developer) installs a "developer"
package (headers, import libraries, .pc file) for some software in the
same directory tree where pkg-config is installed, everything should
just work, even if the .pc file for that software of course doesn't
know where the software actually is installed. This works as long as
the .pc file uses the variable name "prefix" for its installation
prefix. At least GLib, ATK, Pango and GTK does this.
On Unix, pkg-config is built using its own copy of GLib 1.2.8. On
Windows, we use the normal GLib available for Windows (1.3.9
currently). Yes, this does introduce a circular dependency, but that
can be worked around. The circular dependency only appears if one uses
the configure mechanism to build GLib. GLib's configure script checks
for pkg-config. pkg-config depends on GLib. Thus, starting from
scratch, with no GLib and no pkg-config, using configure, there would
indeed be a Catch-22 situation. However, GLib can be built just fine
using the manually written makefiles for mingw or MSVC. And if
somebody does want to build GLib on Win32 using configure, she can
first install a prebuilt pkgconfig.