+2001-10-27 Tor Lillqvist <tml@iki.fi>
+
+ New Win32 feature to make pkg-config useful for users of MSVC:
+ with the flag --msvc-syntax, munge -L and -l flags appropriately
+ for the MSVC command-line compiler. (-I flags are the same.)
+
+ * README.win32: Update.
+
+ * main.c (main): Add --msvc-syntax flag.
+
+ * pkg-config.1: Document it.
+
+ * pkg.h: Declare msvc_syntax.
+
+ * parse.c (parse_libs): Obey msvc_syntax.
+
2001-10-25 Tor Lillqvist <tml@iki.fi>
Improve Windows behaviour: Make it even easier to install
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.
+another Unix variant, as far as pkg-config is concerned.) I don't to
+call this "pure" Win32 target mingw, as pkg-config is usable 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 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).)
+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 (actually, the
-g_win32_get_package_installation_directory() function in GLib) figures
-out the directory by itself.
+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 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.
+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 (1.3.9
+Windows, we use the normal GLib available for Windows (1.3.10
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
"a guesstimated value based on the location of the .pc file" },
{ "prefix-variable", 0, POPT_ARG_STRING, &prefix_variable, 0,
"set the name of the variable that pkg-config automatically sets", "PREFIX" },
+ { "msvc-syntax", 0, POPT_ARG_NONE, &msvc_syntax, 0,
+ "output -l and -L flags for the Microsoft compiler (cl)" },
#endif
POPT_AUTOHELP
{ NULL, 0, 0, NULL, 0 }
#ifdef G_OS_WIN32
int dont_define_prefix = FALSE;
char *prefix_variable = "prefix";
+int msvc_syntax = FALSE;
#endif
+
/**
* Read an entire line from a file into a buffer. Lines may
* be delimited with '\n', '\r', '\n\r', or '\r\n'. The delimiter
int argc;
int result;
int i;
+#ifdef G_OS_WIN32
+ char *L_flag = (msvc_syntax ? "/libpath:" : "-L");
+ char *l_flag = (msvc_syntax ? "" : "-l");
+ char *lib_suffix = (msvc_syntax ? ".lib" : "");
+#else
+ char *L_flag = "-L";
+ char *l_flag = "-l";
+ char *lib_suffix = "";
+#endif
if (pkg->l_libs || pkg->L_libs || pkg->other_libs)
{
libname = g_strndup (start, p - start);
pkg->l_libs = g_slist_prepend (pkg->l_libs,
- g_strconcat ("-l", libname, NULL));
+ g_strconcat (l_flag, libname, lib_suffix, NULL));
g_free (libname);
}
libname = g_strndup (start, p - start);
pkg->L_libs = g_slist_prepend (pkg->L_libs,
- g_strconcat ("-L", libname, NULL));
+ g_strconcat (L_flag, libname, NULL));
g_free (libname);
}
.fi
Remember to use \-\-print-errors if you want error messages.
+.TP
+.I "--msvc-syntax"
+This option is available only on Windows. It causes \fIpkg-config\fP
+to output -l and -L flags in the form recognized by the Microsoft
+Visual C++ command-line compiler, \fIcl\fP. Specifically, instead of
+\fI-Lx:/some/path\fP it prints \fI/libpath:x/some/path\fP, and instead
+of \fI-lfoo\fP it prints \fIfoo.lib\fP. Note that the --libs output
+consists of flags for the linker, and should be placed on the cl
+command line after a /link switch.
+
.TP
.I "--dont-define-prefix"
This option is available only on Windows. It prevents \fIpkg-config\fP
disables said behavior.
.SH WINDOWS SPECIALITIES
-If a .pc file is found in a path that corresponds to the usual
-conventions (i.e., ends with lib\\pkgconfig), the prefix for that
-package is assumed to be the grandparent of the directory where the .pc file
-was found.
+If a .pc file is found in a directory that matches the usual
+conventions (i.e., ends with \\lib\\pkgconfig), the prefix for that
+package is assumed to be the grandparent of the directory where the
+file was found, and the \fIprefix\fP variable is overridden for that
+file accordingly.
In addition to the \fIPKG_CONFIG_PATH\fP environment variable, the
Registry keys
\fIHKEY_CURRENT_USER\\Software\\pkgconfig\\PKG_CONFIG_PATH\fP and
\fIHKEY_LOCAL_MACHINE\\Software\\pkgconfig\\PKG_CONFIG_PATH\fP can be
-used to specify dorectories to search for .pc files. Each (string)
+used to specify directories to search for .pc files. Each (string)
value in these keys is treated as a directory where to look for .pc
files.
extern int dont_define_prefix;
/* The name of the variable that acts as prefix, unless it is "prefix" */
extern char *prefix_variable;
+
+/* If TRUE, output flags in MSVC syntax. */
+extern int msvc_syntax;
#endif
#endif