pkgconfig under Windows ? Was: review FindBlueZ.cmake

[Patrick Spendrin]

Am 02.10.2011 20:16, schrieb Pedro Lopez-Cabanillas:
> On Sunday 02 October 2011, Patrick Spendrin wrote:
>> Am 02.10.2011 00:12, schrieb Pedro Lopez-Cabanillas:
>>> On Saturday 01 October 2011, Alexander Neundorf wrote:
>>>> 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 ?
>>>
>>> Yes
>>>
>>>> Do you use it ?
>>>
>>> Yes. For Qt, KDE and other project types as well.
>>
>> It doesn't work for Qt, 
> 
> Do you know that qmake has an option "CONFIG += link_pkgconfig" for project 
> files (.pro) that enables this: "PKGCONFIG += alsa". 
> 
> http://doc.qt.nokia.com/latest/qmake-project-files.html#configuration-features

I don't speak about qmake. I speak about Qt itself. Also the usage of
qmake based buildsystems is quite rare for obvious reasons.

> 
>> it doesn't work for KDE and most of the other
>> 3rdparty libraries we have also do not use it - also see the mail by Ralf.
> 
> See also my answers to Ralf's questions.

C:\FreeSW\lib\pkconfig\glib-2.0.pc
C:\FreeSW\lib\pkconfig\gthread-2.0.pc
^^ we don't really need those two a lot.

C:\FreeSW\lib\pkconfig\libpng.pc
^^ that one is broken as mentioned by Ralf.

C:\FreeSW\lib\pkconfig\sndfile.pc
^^ our libsndfile package also doesn't provide that one.


>  
>>>
>>>> Does it work with mingw ?
>>>> Does it work with MSVC ?
>>>
>>> Yes, yes. An example of a CMake build system using extensively pkg-config 
> in 
>>> both Windows (MinGW and MSVC) and Linux is FluidSynth:
>>> http://sourceforge.net/apps/trac/fluidsynth/wiki/BuildingWithCMake
>>
>> Finding glib & gthread is not extensively and could work directly from
>> cmake. There are FindG*.cmake scripts available in several locations in
>> KDE which don't rely on pkg-config at all.
> 
> FluidSynth is not Qt nor KDE. It is not even C++, but has a CMake buildsystem.
> 
> glib and gthread are the only mandatory libraries required by FluidSynth, but 
> we also use pkg-config to check for optional ones: libsndfile, pulseaudio, 
> alsa, portaudio, jack, lash, ladcca, and dbus. I would say an extensive usage.

Our dbus package (we use the cmake buildsystem here again) wouldn't even
work here. All the other packages you mentioned except libsndfile don't
matter for us at the moment.

> 
> http://fluidsynth.svn.sourceforge.net/viewvc/fluidsynth/trunk/fluidsynth/CMakeLists.txt
> 
>>> An argument to support using pkg-config for projects that already provide 
> a 
>>> .pc file can be the recent problems with PulseAudio 1.0 and the broken  
>>> findpulseaudio.cmake
>>
>> We don't use pulseaudio at all.
> 
> "We" do:
> 
> http://mail.kde.org/pipermail/kde-buildsystem/2011-September/008162.html

where is the windows relationship there?

> 
>>> Another argument is that looks like KDE would be playing some sort of 
> boycott 
>>> against a freedesktop.org standard.
>>
>> Could you point us to the point where this is written down as a
>> standard? pkg-config is hosted by freedesktop.org, but that doesn't mean
>> it is a standard I would say.
> 
> No, it is not really a standard, because "freedesktop.org is not a standards 
> body" (http://www.freedesktop.org/wiki/Specifications)

aha, so no standard? But still it is supposed to be a standard?

>  
> So, you confirm the boycott, then:
> 
>> I currently don't see any advantage of pkg-config, only disadvantages,
>> so there is no way to use that here.

Yes, I don't care about pkg-config because I think it can be fully
replaced by cmake scripts. If you call it boycott if somebody decides
that a tool simply is not what he wants - then so be it.

Implying that KDE on Windows should change its buildsystem simply
because pkg-config works for you makes no sense.

regards,
Patrick