pkg-config/README.win32
Arch Librarian 1aaee14cab 2001-09-30 Tor Lillqvist <tml@iki.fi>
Author: tml
Date: 2001-09-29 21:05:25 GMT
2001-09-30  Tor Lillqvist  <tml@iki.fi>

	Changes for "pure" Win32 (without Cygwin or similar)
	support. The most important differences compared to pkg-config
	on Unix are:

	We don't use hardcoded PKGLIBDIR paths but deduce the
	installation prefix at runtime.

	Use the normal GLib DLL, not a private copy. Yes, this does
	introduce a circular dependency, but that can be worked around.

	* README.win32: New file.

	* configure.in: Check for Win32. If so, define USE_INSTALLED_GLIB,
	and don't configure in the included glib-1.2.8. Set GLIB_CFLAGS
	and GLIB_LIBS assuming that GLib is installed in the same location
	pkgconfig will be. Check for dirent.h, unistd.h and sys/wait.h
	headers.

	* Makefile.am: If USE_INSTALLED_GLIB, use the GLIB_* values set
	above, and don't make in the glib-1.2.8 subdir.

	* autogen.sh: Use perl -p -i.bak, works better on Win32 (and Cygwin).

	* *.c: Conditionalize inclusions of unistd.h and sys/wait.h.

	* findme.c: Define X_OK on Win32 if necessary.

	* parse.c
	* popthelp.c: Minor Win32 portability ifdefs.

	* parse.c: No need to include <windows.h>.

	* pkg.c: Don't hardcode PKGLIBDIR, but use
	g_win32_get_package_installation_directory() to deduce it.
	(scan_dir): Make a temp copy of dirname with potential superfluous
	trailing slash removed. The Win32 opendir implementation doesn't
	always like those.

	* pkg.h: If USE_INSTALLED_GLIB, include <glib.h> instead of
	partial-glib.h.

	* popt.c (execCommand): Don't compile on Win32.

	* poptconfig.c (configLine): Don't bother with the "exec" stuff on
	Win32, too complex to port, at least for now.
	(poptReadDefaultConfig) Don't bother compiling on Win32, this
	function isn't even called.
2005-07-14 13:04:29 +00:00

41 lines
2.1 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.
We use 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.
The intention is that a developer package for some library being
desribed by a .pc file is installed using some simple installer, that
edits the user-selected installation directory into the .pc file
before storing the .pc file where pkg-config can find it.
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.