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
_______________________________________________
Kde-windows mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kde-windows
