2011/6/8 Alexander Neundorf <neund...@kde.org>: > 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 ?
Our e-mails crossed each-other. Yes you are right default behavior of making find_package(...without REQUIRED) This is a different story for add_subdirectory. >> > 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. Again I agree for find_package since the extra behavior seems backward compatible, (I need more time to think about it) you'll have to take care of name collision with existing user defined OPTION though. -- 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
