mirror of
https://gitlab.freedesktop.org/pkg-config/pkg-config.git
synced 2026-05-15 19:18:09 +02:00
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.
47 lines
2.6 KiB
Text
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.
|