pkgconfig under Windows ? Was: review FindBlueZ.cmake

Pedro Lopez-Cabanillas pedro.lopez.cabanillas at gmail.com
Sun Oct 2 13:53:01 UTC 2011


On Sunday 02 October 2011, Ralf Habacker wrote:
> Am 02.10.2011 00:17, schrieb Pedro Lopez-Cabanillas:
> > On Saturday 01 October 2011, Patrick Spendrin wrote:
> >> The issue with pkgconfig and also the point why we don't use it is the
> >> following: pkgconfig uses .pc files to find out about the layout of a
> >> library. This means that e.g. the installation path is hardcoded into
> >> that file, which makes sense as long as you don't send around packages
> >> containing these files: on a different system those paths will not have
> >> any meaning, so it is completely useless to put those paths in there.
> > The hardcoded path in the .pc file is interpreted (in Windows) relative to 
the
> > directory where the .pc file was found. It is explained in the man page:
> > http://linux.die.net/man/1/pkg-config
> >
> > "Windows Specialities
> >
> > 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 prefix
> > variable is overridden for that file accordingly.
> >
> > In addition to the PKG_CONFIG_PATH environment variable, the Registry keys
> > HKEY_CURRENT_USER\Software\pkgconfig\PKG_CONFIG_PATH and
> > HKEY_LOCAL_MACHINE\Software\pkgconfig\PKG_CONFIG_PATH can be 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."
> Below is the list of packages  of the kde 4.7.0 vc100 release with a 
> pkgconfig file
> 
> c:\Program Files\kde-4.7.0-vc100\lib\pkgconfig/dbusmenu-qt.pc
> c:\Program Files\kde-4.7.0-vc100\lib\pkgconfig/libpng.pc
> c:\Program Files\kde-4.7.0-vc100\lib\pkgconfig/libpng14.pc
> c:\Program Files\kde-4.7.0-vc100\lib\pkgconfig/libssh.pc
> c:\Program Files\kde-4.7.0-vc100\lib\pkgconfig/taglib_c.pc
> c:\Program Files\kde-4.7.0-vc100\lib\pkgconfig/zlib.pc
> 
> The contents are:
> 
> c:\Program Files\kde-4.7.0-vc100\lib\pkgconfig/dbusmenu-qt.pc
> prefix=n:/
> exec_prefix=n:/
> libdir=n://lib
> includedir=n://include/dbusmenu-qt
> 
> Name: libdbusmenu-qt
> Description: Qt implementation of dbusmenu spec
> Version: 0.8.3
> Libs: -L${libdir} -ldbusmenu-qt
> Cflags: -I${includedir}
> 
> c:\Program Files\kde-4.7.0-vc100\lib\pkgconfig/libpng.pc
> prefix=k:/
> exec_prefix=k:/
> libdir=k://lib
> includedir=k://include/libpng14
> 
> Name: libpng
> Description: Loads and saves PNG files
> 
> c:\Program Files\kde-4.7.0-vc100\lib\pkgconfig/libpng14.pc
> Version: 1.4.4
> Libs: -L${libdir} -lpng14
> Libs.private: -lz -lm
> Cflags: -I${includedir}
> prefix=k:/
> exec_prefix=k:/
> libdir=k://lib
> includedir=k://include/libpng14
> 
> Name: libpng
> Description: Loads and saves PNG files
> 
> c:\Program Files\kde-4.7.0-vc100\lib\pkgconfig/libssh.pc
> Version: 1.4.4
> Libs: -L${libdir} -lpng14
> Libs.private: -lz -lm
> Cflags: -I${includedir}
> Name: libssh
> Description: The SSH Library
> 
> c:\Program Files\kde-4.7.0-vc100\lib\pkgconfig/taglib_c.pc
> Version: 0.5.0
> Libs: -Llib -lssh
> Cflags: -Iinclude
> 
> prefix=k:/
> exec_prefix=k:/
> libdir=k:/lib
> includedir=k:/include
> 
> 
> Name: TagLib C Bindings
> Description: Audio meta-data library (C bindings)
> Requires: taglib
> Version: 1.7.0
> Libs: -Lk:/lib -ltag_c
> Cflags: -Ik:/include/taglib
> 
> c:\Program Files\kde-4.7.0-vc100\lib\pkgconfig/zlib.pc
> prefix=k:/
> exec_prefix=k:/
> libdir=k://lib
> sharedlibdir=k://lib
> includedir=k://include
> 
> Name: zlib
> Description: zlib compression library
> Version: 1.2.5
> 
> Requires:
> Libs: -L -L -lz
> Cflags: -I

Those files are broken in a way that the automatic adjustment of the prefix 
will not have any affect.
 
> How could the pathes of these file be interpreted relative to the 
> install root ?

In Windows, only the "prefix:" variable is replaced by the relative location 
of the pkconfig files, but not any other variables which should be declared 
relative to ${prefix}. For instance, these are the contents of some .pc files 
that are working well for me here:

C:\FreeSW\lib\pkconfig\glib-2.0.pc
C:\FreeSW\lib\pkconfig\gthread-2.0.pc
C:\FreeSW\lib\pkconfig\libpng.pc
C:\FreeSW\lib\pkconfig\sndfile.pc

Programs, libraries and headers are installed within the following directory 
structure. The root folder is "C:\FreeSW", but could be any other directory 
name without blank spaces, so "C:\Program Files" should be avoided.

C:\FreeSW\
├───bin
├───share
├───etc
├───lib
│   ├───pkgconfig
│   ├───glib-2.0
│   └───gtkglext-1.0
└───include

File "C:\FreeSW\lib\pkconfig\glib-2.0.pc":

prefix=/target
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
glib_genmarshal=glib-genmarshal
gobject_query=gobject-query
glib_mkenums=glib-mkenums
Name: GLib
Description: C Utility Library
Version: 2.16.3
Libs: -L${libdir} -lglib-2.0 -lintl  
Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib-2.0/include 

File "C:\FreeSW\lib\pkconfig\gthread-2.0.pc"

prefix=/target
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: GThread
Description: Thread support for GLib
Requires: glib-2.0
Version: 2.16.3
Libs: -L${libdir} -lgthread-2.0 
Cflags: 

File "C:\FreeSW\lib\pkconfig\libpng.pc"

prefix=/target
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include/libpng12
Name: libpng
Description: Loads and saves PNG files
Version: 1.2.26
Libs: -L${libdir} -lpng12
Cflags: -I${includedir} 

File "C:\FreeSW\lib\pkconfig\sndfile.pc"

prefix=F:/WHATEVER
exec_prefix=${prefix}/bin
libdir=${exec_prefix}
includedir=${prefix}/include
Name: sndfile
Description: libsndfile
Version: 1.0.24
Requires:
Conflicts:
Libs: -L${libdir} -lsndfile-1
Cflags: -I${includedir}

Regards,
Pedro


More information about the Kde-windows mailing list