On Jun 8, 2011, at 12:08 PM, Alexander Neundorf wrote: > On Tuesday, June 07, 2011 02:34:06 PM Eric Noulard wrote: >> 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. > > I can't think of any reason why somebody would want to use > find_package(...without REQUIRED) instead of optional_find_package(). > > Can somebody else see a reason ? > > >>> 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 ? > > Well, it doesn't have to. > But if packagers requested this for something in KDE, they will also want > this > for non-KDE projects. > And I see no reason why this shouldn't be the default for _every_ > non-REQUIRED > package. > This would make the options available for cmake-based projects more > consistent. > This issue comes up regularly from new users. > > So, I don't see a reason why such an option should not be the default > behaviour and why I should rely on an external extension.
Just something that came to mind... what if one wanted one cmake option that corresponds with multiple find_package()'s. But then wouldn't the following work for that case? option(MYOPTION... ) set(FOO_OPTION ${MYOPTION} CACHE INTERNAL "") set(BAR_OPTION ${MYOPTION} CACHE INTERNAL "") find_package(FOO) find_package(BAR) Clint _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers