KDE Multimedia related CMake question

[Alexander Neundorf]

Hi,

On Wednesday 19 October 2011, Colin Guthrie wrote:
> Hi Alex,
> 
> Harald reckoned you'd be the best person to ask so here goes :D

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.
 
> I appreciate it's late notice but I'll be pushing out a release
> tomorrow, so a quick reply would be very much appreciated if you have time.
> 
> 
> 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 ?
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).

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.
Do you consider "porting" PA to cmake ?
This would make things easier :-)

> 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.
 
> 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.
* 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
* port PA to cmake, and generate a much better PAConfig.cmake
 
> 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.

Alex