From kde-buildsystem Sat May 28 05:46:36 2011 From: Ian Wadham Date: Sat, 28 May 2011 05:46:36 +0000 To: kde-buildsystem Subject: Re: Fixing OpenAL and libsndfile dependencies in kdegames (Was `Re: Message-Id: <201105281546.36542.iandw.au () gmail ! com> X-MARC-Message: https://marc.info/?l=kde-buildsystem&m=130656163823796 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. _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem