KDE Multimedia related CMake question

Wed Oct 19 18:55:12 UTC 2011

Hi and thanks for the prompt reply!

'Twas brillig, and Alexander Neundorf at 19/10/11 18:17 did gyre and gimble:
> please prefer posting to kde-buildsystem (and if you think you can put me on 
> CC additionally).
> So also others can answer and it is searchable on the net.

Noted. :)

>> I've been asked to introduce a CMake ProjectConfig to PulseAudio such
>> that Phonon and other KDE things can find it more easily (there have
>> been various problems with horrible regexp parsing and custom (and
>> different) FindPulseAudio.cmake files being copied around).
>>
>> Now I'm not completely in favour of doing that, because as far as I'm
>> concerned pkg-config should provide all the needed info already, however
>> I'm not completely against shipping CMake stuff with PA upstream either
>> if it's sufficiently easier.
>>
>> However, I'm not 100% certain whether the approach I've taken is the
>> best possible, partly due to strange requirements on the version files
>> such as including boilerplate comparison code which just seems
>> fundamentally wrong!
> 
> In principal yes.
> Starting with cmake 2.8.6 such a template file is shipped with cmake, so 
> developers don't have to write it anymore themselves.
> (...which doesn't help you anything since PA is built using autotools)
> 
>> However, if you could advise, what's best, then I'll take your word for it.
>>
>> My patches to PA to generate the cmake files are shown here:
>> http://colin.guthr.ie/git/pulseaudio/commit/?id=7d611ea27062e38ea083f67894f
>> 74993d062fbb9
>>
>> (keep in mind this is an autotools package that's generating the CMake
>> project config!)
> 
> 
> diff --git a/PulseAudioConfig.cmake.in b/PulseAudioConfig.cmake.in
> new file mode 100644
> index 0000000..caeb8a1
> --- a/dev/null
> +++ b/PulseAudioConfig.cmake.in
> @@ -0,0 +1,13 @@
> +changequote(`[', `]')dnl Set up m4 quoting
> +set(PULSEAUDIO_FOUND TRUE)
> +
> +set(PULSEAUDIO_VERSION_MAJOR @PA_MAJOR@)
> +set(PULSEAUDIO_VERSION_MINOR @PA_MINOR@)
> +set(PULSEAUDIO_VERSION @PA_MAJOR at .@PA_MINOR@)
> +set(PULSEAUDIO_VERSION_STRING "@PA_MAJOR at .@PA_MINOR@")
> +
> +set(PULSEAUDIO_INCLUDE_DIR "@PA_INCDIR@")
> +set(PULSEAUDIO_LIBRARY "@PA_LIBDIR@/libpulse at PA_SOEXT@")
> +ifelse(@HAVE_GLIB20@, 1, [dnl
> +set(PULSEAUDIO_MAINLOOP_LIBRARY "@PA_LIBDIR@/libpulse-mainloop-
> glib at PA_SOEXT@")
> +])dnl
> 
> I guess PA_LIBDIR and PA_INCDIR are absolute paths ?

Yeah I define those in the configure.ac so they are absolute.

> Then this file doesn't work under Windows (since there the user decides when 
> installing a binary package where it will go, not when the package is built).

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. Longer terms this may become possible,
but certainly not an immediate concern.

> Having the version number there is nice and easy to do.
> 
> Beside that, in general it looks ok, but not perfect.
> 
> I'm not really sure it is really worth it, to ship this file now in this 
> state.

Other than the windows issue, what else specifically makes it not worth
it? I'm just trying to understand things better.

> Do you consider "porting" PA to cmake ?
> This would make things easier :-)

I can quite honestly say that that is never going to happen. I've fought
enough with cmake (including getting segvs - just remove the NO_MODULE
flag from the last commit I linked[1] and cmake helpfully crashes itself
- presumably due to unprotected recursion) to really not see any benefit
over autotools. As said before, I still don't fully understand why the
pkg-config stuff is not sufficient, seeing as it is so widely used, but
I don't want to get dragged into politics so I'll shut up now :D

>> 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!

>> I'm also not sure whether I should be hard-coding the library files as I
>> do in the file or if it would be better to use find_library() macro. I
>> figured hard-coding was more sensible to avoid additional processing?
> 
> The additional processing is no problem (especially considering the issue with 
> the hardcoded absolute path). 
> 
> To make it short, I think I wouldn't release it in this state.
> 
> I see the following options:
> * make the PAConfig.cmake use find_library() and find_path() calls instead of 
> hardcoding the results. This should make it work also under Windows.

OK, I can do that easily enough even if Windows isn't a key concern.

> * write an "official" FindPA.cmake and submit it eother directly to cmake (and 
> maintain it there) or to extra-cmake-modules (new project, no releases yet) 
> via the kde-buildsystem mailing list

Again, I don't see the difference in shipping this separately to PA for
the reasons posted above. I don't see why it's OK to ship a "project
config" with the project itself but not the Find* script. The two do the
same job and if there is only "project config" files and no Find* then
the "nothing installed" case is identical (i.e. nothing installed) and
then surely any find_package(PulseAudio) calls would return the same
results.

>> I also found that in Phonon, this project config was not used as the
>> (local) FindPulseAudio.cmake file seemed to take precedence.
>>
>> I worked around that with this commit:
>> http://colin.guthr.ie/git/phonon/commit/?h=4.5&id=06a3d4ac02fbc9197d1c1bd4a
>> 9cef658713303b1
>>
>> Harald reckoned it shouldn't be necessary, but when stracing cmake with
>> -e access or -e open, it didn't even try and look at the project config
>> as long as the FindPulseAudio.cmake file existed - removing it
>> completely worked fine and used the project config.
> 
> Yes. 
> This is also documented on the cmake man page in the section for 
> find_package(). CMake first checks for a FindFoo.cmake, and if it's not found, 
> it searches for a FooConfig.cmake.
> This can be skipped by using find_package(... NO_MODULE), then it directly 
> starts searching the FooConfig.cmake file.

Cool, so if I want to prefer the project config data while maintaining
the Find* script for compatibility with older PA version that ship
without a project config, then the above change is valid. Thanks for
confirming :)

Cheers

Col

1.
http://colin.guthr.ie/git/phonon/commit/?h=4.5&id=06a3d4ac02fbc9197d1c1bd4a9cef658713303b1

-- 

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/