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
|
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.
--Tor Lillqvist <tml@iki.fi>
|
