pkgconfig under Windows ? Was: review FindBlueZ.cmake

[Alexander Neundorf]

On Sunday 02 October 2011, Ralf Habacker wrote:
> Am 02.10.2011 15:53, schrieb Pedro Lopez-Cabanillas:
> > Those files are broken in a way that the automatic adjustment of the
> > prefix will not have any affect.
> 
> which means the recent state of pkg-config support for kde windows is
> broken
> 
> >> 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
> 
> which mean to have propper pkg-config support for kde-windows packages
> every package requires a pkg-config file with a "relative" based content.
> These files are created - as far as i know - by the build system of the
> related package from a hand created template file (probably
> <package-name>.pc.in)
> 
> > glib_genmarshal=glib-genmarshal
> > gobject_query=gobject-query
> > glib_mkenums=glib-mkenums
> > Name: GLib
> > Description: C Utility Library
> > Version: 2.16.3
> 
> The template files and the related build system stuff may require some
> changes in case of package update (version fix, adding/removing  libraries)
> 
> > Libs: -L${libdir} -lglib-2.0 -lintl
> 
> also this line indicates that there may be dependency libraries listed
> in the pkg-config file - this need to be maintained - who will do this ?
> 
> - how does this fit with dependency handling of the package build
> systems for example when there is a 3rdparty glib package refering to
> -lintl, where the local build intl package provides intl3 or something
> else, which results into inconstency
> 
> Who will make this happen for all the package and build system used by
> kde on windows packages now and in the next years ?
> 
> What are the benefits of having pkg-config support against the
> disadvantage that resources are bound by maintaining this feature ?
> 
> The required effort (and required time) should not be under estimated.

I fully agree.
My question was actually related to whether we should make use of pkg-config 
to find "other" software, not whether we should encourage "KDE" software to 
install pc-files.

For the second point, for the very same reason, I will discourage KDE software 
to install pc-files.
CMake 2.8.6 will be able to provide that information too:
cmake --find-package -DNAME=JPEG -DLANGUAGE=C -DCOMPILER_ID=GNU -DMODE=COMPILE
'-I/Usr/local/include'

It will also install a cmake.m4 file. This means, in autotools-based projects, 
instead of using the m4-macro to call pkg-config to print this information, 
the new m4-macro can be called to have cmake print this information.

This big advantage for any cmake-based library is, that it only has to install 
a cmake Config.cmake file. This file will then of course be usable by other 
cmake-based projects (as it is now), but also by autotools-projects, those 
have to use that new m4-macro instead of the pkg-config macro.

Alex