pkgconfig under Windows ? Was: review FindBlueZ.cmake

[Ralf Habacker]

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.

Ralf