KDE Multimedia related CMake question

[Alexander Neundorf]

On Thursday 20 October 2011, Colin Guthrie wrote:
...
> 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

For even more detailled discussion of this, you should probably go to the 
cmake or cmake-developers list.

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

It is a little bit better than the fully hardcoded paths.
Under Linux it should give the same results as before, but now probably it 
should be checked whether all finds were successful.

Under Windows the HINTS dirs will usually be wrong, but there is at least a 
chance that the find-calls actually find PA.
But then it really should check whether they have actually been found.

So, it's ok, but not perfect.

Alex