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

[Alexander Neundorf]

On Saturday 28 May 2011, Ian Wadham wrote:
> On Thursday 26 May 2011 10:27:50 am Michael Pyne wrote:
> > On Wednesday, May 25, 2011 00:25:57 Raphael Kubo da Costa wrote:
> > > It will then be just a matter of intalling two more packages,
> > > and I don't see how this should make things more difficult to
> > > cmakekde/kdesrc-build users, or to anyone at all.
> 
> That was a sticking point.  Not everyone wants to stop what they are
> doing and install packages just to get KDE Games to build.  People
> in KDE Games and KDE Edu generally prefer optional dependencies
> for all the (independent) apps. Their interests may lie with games other
> than KGoldrunner and Granatier.  If they do, then they do not want to
> install OpenAL and SndFile in their system.  That's just a small example.
> KDE Games and KDE Edu have some more exotic dependencies.
> 
> So I had to abandon the idea of making OpenAL and SndFile
> REQUIRED dependencies within the kdegames module, because
> it is a bit anti-social.
> 
> > Although I certainly don't want to tell kdesrc-build how they have to use
> > 
> >  the tool, it has always been my intention that they at least will read
> >  through CMake output in the event of CMake failures. To that end
> >  kdesrc-build symlinks the cmake log to error.log and informs the user of
> >  where to find the file so they can review it.
> > 
> > In addition kdesrc-build will continue to build everything else possible
> > in
> > 
> >  a given run, so please don't be too concerned with causing CMake to fail
> >  if there's an actual error.
> 
> Hello Michael.  First of all, please let me say how admirable I find
> kdesrc-build and how happy I am using it.  In the last two months it
> has seen me through many difficult times, especially because of the
> way it transparently checks out code from git or svn, as required.
> 
> It is great also that kdesrc-build highlights missing REQUIRED packages
> and compilation/linking failures and takes you direct to the heart of the
> problem via the error.log link.
> 
> > I propose assuming that one or both of kgoldrunner and granatier are
> > built
> > 
> >  by default, and to fail CMake if libsndfile/OpenAL are not found. In the
> >  error message that would appear, instead of saying simply to install
> >  OpenAL, also give the alternative of adding -DBUILD_kgoldrunner=OFF and
> >  -
> > 
> > DBUILD_granatier=OFF. That's about the best option I can see at this
> > point.
> 
> That's a good option, but I do not know for sure how to get those -Ds
> into the mix and at the right point, in all circumstances.  Nor do I think
> everyone who builds KDE Games can be expected to know that.
> 
> I can key in a command cmake -DBUILD_... but I do not think
> kdesrc-build -DBUILD_... or cmakekde -DBUILD_... would work as required.
> I think(?) a cmake-options -DBUILD_... line in the kdegames section of
> .kdesrc-buildrc would do the trick, but then not everybody is using
> kdesrc-build (yet :-) ).

Do "make edit_cache" or "cmake-gui ." in the build dir, and it will show you 
all available options.
This is the recommended way to change options in cmake-based builds.
People building software using cmake are supposed to know that.

> In the "good old days" of just "make", you could do export BUILD_... etc.
> and make/cc would pick up the options even if they were run inside a
> script. IIRC that would also override any setting of the option that was
> embedded in the script.  Can cmake do that?  How can I be sure?  (I have
> looked at the cmake doco).

With cmake you do that by setting variables in CMakeCache.txt. This can be 
done via -DNAME=value, manually editing CMakeCache.txt or running "make 
edit_cache".

...
> I think what all this boils down to is that cmake cannot be all things to
> all men.  It is a makefile generator, but it is being stretched into being
> a software configuration manager - and doing quite a good job.
> 
> So what I think we really need (at least) is a pre-analyzer of
> dependencies, driven by a data source that states what depends on what and
> why.  

I seriously think that this should be done by/via cmake.
The CMakeLists.txt state which packages are used, and for what they are used.
Using an additional data source (like e.g. an xml file which documents which 
targets use which packages and why) is not a good idea, it will be out-of-sync 
(since getting out-of-sync does not break the build). So this would be dead 
data.

What I do not like about the macro_log_feature() is the REQUIRED keyword, it 
leads to broken cmake files.

When using 
find_package(Foo REQUIRED)

you can be sure that if cmake code following that line is executed, that Foo 
has been found successfully, and you can without further checking use the 
variables it defines.
If a package is just optional, you are expected to check afterwards whether it 
has been found or not.

macro_log_feature(REQUIRED)
does not behave like this, cmake processing continues, and I'm not sure every 
developer adds the necessary checking whether it has been found or not.

> Then we could run that before attempting a build, evaluate which
> dependencies we wish to meet, which libraries we would like to have and
> which applications or features of apps we can do without.
> 
> I think something like that might help with the REQUIRED dependencies
> also.  It is frustrating to have to got through several build attempts in
> order to meet the REQUIRED dependencies one by one.  

This is true, but ass described above, there is a reason why it is this way.

CMake 2.8.3 and newer comes with an improved module "FeatureSummary.cmake".
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#module:FeatureSummary

This can e.g. report *all* packages which have been searched, without any 
extra work to be done by the developer, cmake records all that automatically.

The extra information, like URL or description, can be set via 
set_package_info() and add_feature_info().
In theory, this should be done inside the Find-module.

Could this be extended in some way so it becomes more useful ?
Maybe something like:
add_package_target(<package> <target> <purpose of package in target>)

so that you could do

add_package_target(OpenAL kgoldrunner "Provides 3D sound for kgoldrunner")
...
add_package_target(OpenAL granatier "Makes bombs explode around you")

and in the log you would get:

Not found:

OpenAL <http://connect.creativelabs.com/openal/default.aspx>, a free 3D audio 
API
* used by: 
 ** kgoldrunner: provides 3D sound for kgoldrunner
 ** granatier: Makes bombs explode around you
 ...

What do you think ?
Would something like this make sense ?
Other ideas ?


Alex