On Wednesday, June 08, 2011 08:45:56 PM Eric Noulard wrote: > 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.
Yes, for me adding this to find_package() is the more important and more general useful one. Alex _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
