pkgconfig under Windows ? Was: review FindBlueZ.cmake

[Alexander Neundorf]

On Tuesday 18 October 2011, Pedro Lopez-Cabanillas wrote:
> On Tuesday 18 October 2011, Alexander Neundorf wrote:
> > On Saturday 01 October 2011, Patrick Spendrin wrote:
> > > Am 01.10.2011 21:33, schrieb Alexander Neundorf:
> > > > On Wednesday 21 September 2011, Raphael Kubo da Costa wrote:
> > > >> Michael Jansen <kde at michael-jansen.biz> 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
> > > disadvantages.
> > 
> > So, I'm not sure what the conclusion is.
> > It sounds like the find-modules have to find the stuff successfully also
> > without pkg-config under Windows.
> > And if this is a requirement, then I ask myself, if the find-modules have
> > to be written in a way that they work without pkg-config just as good as
> > with pkg-config, then why do we need the pkg-config stuff in them at
> > all, I mean e.g. under Linux ?
> > 
> > Alex
> 
> On the other hand, I have the impression that you simply made a rhetoric
> question, that you have taken your decision beforehand, and you only want
> to listen a confirmation of your own opinion, dismissing and silencing the
> dissenting voice.

Not really.
Feel free to convince me otherwise, but keep the precondition that it *must* 
work without pkg-config under Windows in mind, at least that's how I 
understood our Windows developers.

If you look at what I did until now in extra-cmake-modules: I did not remove 
the pkg-config stuff there, instead I removed the "if(NOT WIN32)" around them, 
so I did actually extend pkg-config usage.
But if the Windows developers say they don't want the results from pkg-config 
even if it's installed, then really, what does it gain us ?

(This is not meant to be rhetoric).

Alex