1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
|
pkg-config on Win32
===================
This file describes pkg-config for "native" Win32. (On Cygwin,
pkg-config builds fine right out of the box. Cygwin is just another
Unix variant, as far as pkg-config is concerned.) I don't call this
"native" Win32 target MinGW, as pkg-config on Windows is supposed to
be useable also by MSVC 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 some optional entries in the Registry: Firstly, the
path to the pkgconfig installation prefix. This can be either
user-specific in HKCU\Software\pkgconfig\InstallationDirectory or for
the whole machine in HKLM\Software\pkgconfig\InstallationDirectory.
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 figures out the directory by itself. (The
g_win32_get_package_installation_directory() function in GLib.)
Additionally, in addition to the PKG_CONFIG_PATH environment
variables, any string value in the Registry key
HKLM\Software\pkgconfig\PKG_CONFIG_PATH (or HKCU\...) is assumed to be
a directory name and is searched for .pc files.
When pkg-config is invoked on Windows, it tries to set the "prefix"
variable for each .pc file read to "top" of the directory tree where
the .pc file is located. This is done only if the .pc file is in a
path that ends in "lib/pkgconfig". Thus, if an end-user (developer)
installs headers, import libraries and .pc files in the normal
subdirectories under some random directory, everything should just
work, even if the .pc file for that software doesn't know the true
directory name, but contains the path used on the packager's
site. 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 (2.0.x). Yes,
this does introduce a kind of 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.
--Tor Lillqvist <tml@iki.fi>
|
