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 found... 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) if( ZLIB_VERSION VERSION_GREATER 1.3.0 ) find_package(FOO REQUIRED) endif() 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. Andreas -- Tomorrow, this will be part of the unchangeable past but fortunately, it can still be changed today. _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem