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

[Ian Wadham]

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

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

Re REQUIRED and optional packages.  Cmake stops dead after the config
phase if a REQUIRED package is not found and the messages about this are
right at the end of the log and easy to see, even if you are not re-directing
the log output.  Kdesrc-build re-directs log output and points you to an error
log and again the messages are right at the end.

If an optional package is not found, cmake keeps going.  It does produce a
summary (or rather KDE's macros do), but it is buried in a much longer log.

I often look at that section of the log, but not always.  IMHO it is easy to
miss an "important" optional dependency, especially where there is a
convention to use optional dependencies only, as in KDE Games and
KDE Edu (and for good reason).

The effect of an optional dependency on a non-KDE library in a collection
of apps can range from "application won't work without it" to "application
will work but will be missing some feature".  The feature might be more or
less important to various groups of people.

For example, KDE Games has optional dependencies on OpenGL and
QtOpenGL.  Those dependencies are commonly met nowadays, but were
not when the games that use them first appeared.  Kubrick, a Rubik's cube
game, will not work without OpenGL.  KSudoku will work, but will be missing
the 3-D versions of the game.  It will still have several 2-D versions.

Kubrick will be dropped from the build if OpenGL or QtOpenGL is not found.
To realize this has happened, the builder must scroll to the right point in
the log.

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.  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.  As an example,
the soprano/strigi/nepomuk structure springs to mind ...

All the best, Ian W.