KDE Multimedia related CMake question

[Colin Guthrie]

Hiya,

'Twas brillig, and Alexander Neundorf at 19/10/11 20:25 did gyre and gimble:
> On Wednesday 19 October 2011, Colin Guthrie wrote:
>> I'm not super fussed on Windows at the moment as although we ship
>> Windows builds for PA, none of the backends for windows are PA aware and
>> thus it's a rather moot point. 
> 
> I don't understand. There are builds of PA for Windows, but they are useless 
> because they don't have any backend ?

Useless for phonon yes, but not useless in their own right. They can for
example accept network connections from Linux machines such that the
audio can come out the speakers on the windows box.

> One important thing to keep in mind is, that once you install such a file, 
> source compatibility must be kept for it.
> By doing a source incompatible change to such an installed file, you can break 
> the build of existing projects.
> http://techbase.kde.org/Policies/CMake_and_Source_Compatibility

Yeah, that's one of the reasons I want to make sure I don't make a
complete hash of it, and hence why I seek the advice of those most
knowledgeable :D

> One point is that pkg-config is an additional dependency on some platforms, 
> and works not everywhere very well (i.e under Windows).

Yeah, but my concerns of windows are kinda covered, so not a biggie in
my book :)

>>>> I'm wondering if it's actually better to ship a FindPulseAudio.cmake
>>>> official system which in turn uses pkg-config rather than this project
>>>> config (although that seems somewhat counter intuitive).
>>>
>>> No, this wouldn't make sense.
>>> A FindPulseAudio.cmake contains the plan how to find PulseAudio.
>>> But it will only be there on the system if PA is installed, and it has to
>>> be found itself.
>>
>> Now Harald made this argument in the past too, but I simply don't
>> understand it.
>>
>> I mean, I've been recommended to ship a "project config". Obviously this
>> "project config" can be present or not depending on whether PA devel
>> headers+libs are available. Is this not identical to having a Find*
>> script available or not? I mean I really don't see any logical
>> difference to how things behave here. I'm no doubt missing something
>> *really* obvious!
> 
> It's basically a matter of definition.

...snip...

Thanks for the explanation. I do get your point but by the same token,
I'm not 100% convinced by the arguments of how different they really are
:D But that's not really related to this particular problem, so I won't
get side tracked :p


Anyway, I've modified things such that it now looks like this on my system:

set(PULSEAUDIO_FOUND TRUE)

set(PULSEAUDIO_VERSION_MAJOR 1)
set(PULSEAUDIO_VERSION_MINOR 0)
set(PULSEAUDIO_VERSION 1.0)
set(PULSEAUDIO_VERSION_STRING "1.0")

find_path(PULSEAUDIO_INCLUDE_DIR pulse/pulseaudio.h HINTS "/usr/include")
find_library(PULSEAUDIO_LIBRARY NAMES pulse libpulse HINTS "/usr/lib64")
find_library(PULSEAUDIO_MAINLOOP_LIBRARY NAMES pulse-mainloop-glib
libpulse-mainloop-glib HINTS "/usr/lib64")



This works fine, and builds OK, but I'm still a little concerned about
using find_path() and find_library() rather than hard coded paths.

I'm setting the PULSEAUDIO_FOUND variable unconditionally, but relying
on the results of macros to actually find something. Is this definitely
the best setup I could hope to achieve or should I put the set() calls
inside a conditional that checks the the variables filled in by the
find_*() calls actually contain data?

Cheers

Col


-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/