2011/6/7 Alexander Neundorf <neund...@kde.org>: > On Monday, June 06, 2011 03:26:03 PM Brad King wrote: >> On 06/04/2011 06:30 AM, Alexander Neundorf wrote: [...]
>> > >> > What do you think about adding the keyword OPTIONAL to add_subdirectory ? >> > >> > Both have been proven useful, the one for find_package() especially for >> > packagers. >> >> Ditto previous response. These commands are primitives. We should not >> extend them with features unrelated to their basic purpose. > > While this is correct, it also keeps cmake a bit low-level. > For this reason, we created such macros in KDE. > Now our developers write stuff outside KDE, so either they can't use it, or > they create copies of these files. > This may be ok, but having 50 or 100 versions of these files and macros around > in the net, some probably differing slightly, is also not a nice situation. Then it is possible to create a new CMake module, say UseEnhancedConfigure.cmake which could be included in CMake as a contributed module maintained by KDE dev. This new module would define something like: optional_find_package(). optional_add_subdirectory() this would make the feature available upstream, thus available outside KDE and does not add extra feature to builtin configure. > > These two OPTION features in this email are IMO features which are useful in > many projects and which would make using cmake-based projects easier for users > (people compiling the software), since they could expect that if packages can > be disabled, that this will be done via an option with a name which always > follows the same scheme. I totally agree with that but I think it does not implies this has to be done by builtin find_package/add_subdirectory ? -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
