Automatic recording of required packages...

Andreas Pakulat apaku at
Mon Nov 1 18:21:29 CET 2010

On 01.11.10 17:50:17, Michael Jansen wrote:
> > Also, I'd like us to stay as close to normal cmake behaviour as possible,
> > and to use as few own cmake modules as possible (...I know I know).
> > And the behaviour we are using with macro_log_feature() would never be
> > accepted into upstream cmake. It works around the assumptions built into
> > cmake.
> Then cmake is fundamentally broken and refuses to fix it. When checking for 
> dependencies check for all of them and tell me the results all at once.

While I agree that its annoying and somewhat wrong, its also not possible
to fix this I think. CMake files are highly dynamic and hence its possible
that one piece of a project requires a certain package, but only if some
flag is set or some other optional dep is being found. In such a case cmake
cannot know that requirement unless the condition for requiring it is
matched. Which in turn may not be the case because a package is not

So in such cases you'd end up with a list of requirement thats not really
yet final. You may install all of them and still be required later on to
install more. Something like this for example:

find_package(ZLIB REQUIRED)

  find_package(FOO REQUIRED)

is valid CMake code that'll still leave you with 2 runs necessary to find
out all required packages if zlib is not installed.

Hence cmake would need to change its logic that all packages that are today
REQUIRED need to be listed 'upfront' in a plain list without surrounding
logic. And thats something you won't be able to get past the devs as its a
substantial change in the language.


Tomorrow, this will be part of the unchangeable past but fortunately,
it can still be changed today.

More information about the Kde-buildsystem mailing list