pkgconfig under Windows ? Was: review FindBlueZ.cmake
Alexander Neundorf
neundorf at kde.org
Mon Oct 3 16:04:12 UTC 2011
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
More information about the Kde-buildsystem
mailing list