pkgconfig under Windows ? Was: review FindBlueZ.cmake

[Pedro Lopez-Cabanillas]

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

Yes, without proper fixes those .pc files are useless.

> >> 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)

Correct. It is usually created by the build system from a template. For 
instance, these templates belong to my Drumstick libraries:

http://drumstick.svn.sourceforge.net/viewvc/drumstick/trunk/drumstick-
file.pc.in

http://drumstick.svn.sourceforge.net/viewvc/drumstick/trunk/drumstick-
alsa.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 ?

I've not hacked the posted glib/gthread/libpng.pc files in any way, they come 
directly from the DEV packages distributed by Tor Lillqvist that are available 
here: http://www.gtk.org/download/win32.php

So, upstream works for me in this case. For libsndfile, I've asked the author  
to include a .pc file in his windows packages, and he did it iirc. For other 
libraries, if something is broken upstream I would try to fix, report and 
provide patches. The usual business.

> - 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've already said that I'm not advocating drastic changes in kde-windows. 

I think that it would be nice if all the dependencies should adopt the cmake 
build system, or provide a .cmake support file. But when it is not possible 
and we need to create custom FindXXXX.cmake macros, they can use pkg-config  
and there is a reliable way to make it work in Windows.

Regards,
Pedro