KDE Multimedia related CMake question

Wed Oct 19 19:25:06 UTC 2011

On Wednesday 19 October 2011, Colin Guthrie wrote:
> 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=7d611ea27062e38ea083f678
> >> 94f 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. 

I don't understand. There are builds of PA for Windows, but they are useless 
because they don't have any backend ?

If PA is a UNIX-only thing, then it's no problem if the files are not ok for 
Windows.

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

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

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

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

Find-modules search for a package, therefor they must be in a well-known 
location (so cmake doesn't have to search for them). This is in the cmake 
Modules/ directory, and the directories listed in CMAKE_MODULE_PATH (which is 
set by the project).
Beside that there is no search routine for Find-modules in cmake.
Relatively often people ask whether it makes sense to install some 
FindFoo.cmake modules into the share/cmake/Modules/ directory, so that then 
this Find-module is available.

This is not a good idea, because this directory is only searched by that 
version of cmake to which it belongs (e.g. I have like 10 different cmake 
versions installed, each one with its own share/cmake/Modules/ directory).

To improve situation in this regard, and to make it easier to get information 
from installed libraries into cmake-based builds, the Config.cmake files were 
"invented". They are in principle similar to pkg-config pc-files.
They are installed by the library, and they are searched for in a set of 
directories (see find_package() documentation in the cmake man page). 
Additional search directories can be set via the CMAKE_PREFIX_PATH env.var 
(also similar to pkg-config).
The search directories are not in cmake's prefix (like share/cmake/Modules/ 
is), but in the prefix of the installed packages (e.g. /opt/mylib/ ).
This makes it possible that no matter how many different versions of cmake are 
installed, they all can find it.

So, a FooConfig.cmake files doesn't search for Foo, it belongs to Foo and 
"knows" everything about the installed Foo.

The Config.cmake files are more powerful than pkg-config pc-files, since they 
can carry any information by simply setting some variables, they support 
installing different builds of the same library (e.g. debug and release builds 
under Windows), and, they do not simply hardcode some compiler/linker flags 
and print them to stdout. Instead they just provide the information, and at 
build-time of the using project this information is turned into proper 
compiler/linker flags for the compiler which is used then (which may support 
other flags than those recorded in the pc-file).

So, Find-modules and Config-files are two different kinds of files, with 
different purpose and which are handled differently.

Alex