Fixing OpenAL and libsndfile dependencies in kdegames (Was `Re: KDE/kdegames')

Ian Wadham iandw.au at gmail.com
Fri May 20 07:58:12 CEST 2011


On Thursday 19 May 2011 2:35:13 am Raphael Kubo da Costa wrote:
> Raphael Kubo da Costa <kubito at gmail.com> writes:
> > I saw the commit message by chance in #kde-commits and decided to take a
> > look.
> >
> > From what I understood, you want both libsndfile and OpenAL to be hard
> > (ie. required) dependencies for Granatier and KGoldRunner, but only if
> > they are built (ie. if one passes -DBUILD_granatier=OFF and
> > -DBUILD_kgoldrunner=OFF), kdegames should build just fine without
> > libsndfile and OpenAL installed in the system.
> >
> > In this case, wouldn't it be enough to call find_package(SndFile) and
> > find_package(OpenAL) and then add the respective macro_log_feature()
> > calls with the `REQUIRED' parameter set to TRUE instead of FALSE?
> >
> > By putting these commands inside granatier/CMakeLists.txt and
> > kgoldrunner/CMakeLists.txt, you avoid calling them when granatier and
> > kgoldrunner are not build, while still failing to build when they are
> > not found.
> 
> I'm replying to this list and thread instead of release-team@ as the
> subject is more appropriate to be discussed here. I also suggest
> subscribing to this list, as more people might want to give their
> suggestions and they might forget to CC you.
> 
> So what I have in mind is the following:
> 
>   * Granatier and KGoldRunner are optional parts of kdegames (ie. one
>     can call cmake with -DBUILD_granatier=OFF and
>     -DBUILD_kgoldrunner=OFF and none of them will be built).
>   * If one chooses not to build Granatier and KGoldRunner, CMake must
>     not check for libsndfile and OpenAL.
>   * If one does choose to build Granatier and/or KGoldRunner, CMake must
>     check for both libsndfile and OpenAL, and fail at the end of the
>     configuration phase (ie. after cmake runs and before you run make)
>     if either of them (or both) is not found.
> 
> So the attached patch:
> 
>   * Moves FindSndFile.cmake to the top-level cmake/modules directory
>     (you might want to avoid this as kdegames is splitting in git).
>   * Unconditionally adds
>         macro_optional_add_subdirectory(granatier)
>         macro_optional_add_subdirectory(kgoldrunner)
>     to the top-level CMakeLists.txt
>   * In {granatier,kgoldrunner}/CMakeLists.txt it calls
>     find_package()+macro_log_feature() for both OpenAL and
>     libsndfile. As `REQUIRED' is not passed to find_package(), CMake
>     keeps going until the end, when the build fails if the dependencies
>     are not met, as macro_log_feature() is called with required=TRUE.
> 
> Is it clear now?
> 
Yes, thank you very much, Raphael.  What was not clear to me before was
the usage of -DBUILD_* and the fifth parameter of macro_log_feature().
I also browsed around in the kdelibs/cmake/modules source code and all
is now clear.

I am concerned about using -DBUILD_*.  It is a good idea, but people build
KDE Games all the time and for various reasons other than releasing,
packaging and distributing.  For example, they are games developers or
want to play (test :-) ?) the very latest versions.  I do not think they will
all know about the BUILD_* variables of KDE's build macros and anyway
they might be using a script to run CMake, such as cmakekde or kdesrc-build.

I toyed with doing set (BUILD_kgoldrunner FALSE) in kdegames/CMakeLists.txt,
but that means that you have to test for  "OpenAL found" as an optional
dependency at the KDE Games level, which puts us back where we started.

I also played with message (WARNING "...") if Granatier/KGoldrunner could
not be built as required, but found it hard to warn, in a way that would
always be seen, that part of KDE Games would be missing, even if the
rest built correctly.  The module generates a large CMake and Make log.

I see the FindPackageLog.txt file in build/kdegames also contains all the
macro_log_feature() information for packages found and not found.

All the best, Ian W.


More information about the Kde-buildsystem mailing list