pkgconfig under Windows ? Was: review FindBlueZ.cmake

Patrick Spendrin ps_ml at
Sat Oct 1 21:18:56 UTC 2011

Am 01.10.2011 21:33, schrieb Alexander Neundorf:
> On Wednesday 21 September 2011, Raphael Kubo da Costa wrote:
>> Michael Jansen <kde at> writes:
>>> Not sure here. After a (short) talk to some kde windows guys i remember
>>> he said there is pkgconfig for windows but it is considered completly
>>> broken. I think thats why most modules do that magic. Do ignore it on
>>> windows even if there.
>> I've often times heard non-KDE people say pkgconfig used to be broken
>> but should work fine nowadays, so I'm a bit confused here. It'd be nice
>> if the kde-windows guys could provide more details on what's the current
>> state of pkgconfig for them.
> Yes.
> Also, whenever I said somewhere that our cmake files must be able to find 
> stuff also without pkgconfig, people replied that nowadays it works just fine 
> under Windows.
> So, Windows developers: what's the current state of pkg-config under Windows ?
> Does it work ?
Well, it runs.

> Do you use it ?
Not in a sense where I want to.

> Does it work with mingw ?
> Does it work with MSVC ?
The issue with pkgconfig and also the point why we don't use it is the
following: pkgconfig uses .pc files to find out about the layout of a
library. This means that e.g. the installation path is hardcoded into
that file, which makes sense as long as you don't send around packages
containing these files: on a different system those paths will not have
any meaning, so it is completely useless to put those paths in there. So
what to do? One could argue to add an option to pkgconfig to replace
those paths, which is not the best idea either - also it would involve
somebody (in the end: me) hacking on pkgconfig.

To conclude:
At the moment it doesn't make sense to use pkgconfig for us on Windows -
we only gain more work load from it. It might make sense for really
small projects or corner cases to use pkgconfig (e.g. if you'd need to
rewrite the buildsystem for glib otherwise), but for us, it has only

> Alex

More information about the Kde-buildsystem mailing list