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