2011/6/6 Alexander Neundorf <neund...@kde.org>: > On Sunday, June 05, 2011 11:50:50 PM Eric Noulard wrote: >> 2011/6/4 Alexander Neundorf <neund...@kde.org>: >> > Hi, >> > >> > again from the KDE sprint... >> > >> > 1) We have a macro >> > macro_optional_find_package(). >> > The purpose is to be able to build without a specific package even if >> > that package is installed and would actually be found by the >> > find_package() call. >> > >> > Basically this is a wrapper around find_package(), but additionally it >> > adds an option WITH_Foo, which is enabled by default. >> > If disabled, the actual find_package() is not executed, and the variables >> > FOO_FOUND/INCLUDES/LIBRARIES are reset to empty, so that even if the >> > package hasn't been searched this time, results from previous runs are >> > discarded. >> > >> > What do you think about adding this as a built-in feature to >> > find_package(), i.e. add a argument OPTIONAL to find_package(), then >> > probably also a "COMMENT". >> >> I'm not sure about this feature and since we already have REQUIRED why >> would be the meaning of OPTIONAL? > > Using OPTIONAL and REQUIRED together should be considered an error. > OPTIONAL means you can disable the searching so that it will also not be > "found" even if it is actually installed.
Yes I think get your point. I was just thinking that not specifying REQUIRED already means OPTIONAL whereas specifying OPTIONAL means "could be disabled". >> May be some syntax like >> >> find_package(Foo IF <VarName>) would be clearer. >> >> find_package(Foo IF BUILD_WITH_Foo) >> >> would create option BUILD_WITH_Foo >> (default value would the value of BUILD_WITH_Foo_Default var or ON if >> it is not defined) >> and the search of the package will be done iff the option is ON. > > Maybe. > I thought OPTIONAL would be good since it hints at "OPTION", and it is an > option which is created for disabling it. > Could also be "OPTION" instead of "OPTIONAL". I'd prefer OPTION over OPTIONAL I think it's less confusing with REQUIRED. My idea with IF was a little broader than OPTION you could feed IF argument with an existing var (not necessarily an option) and the package search would be done if the var evaluate to true/on/yes.... That way one can encode several ways of enable/disabling a find_package subset. If no var is defined then find_package may create an option using this name with a default value set to ON. However, may be the IF idea is simply overkill. -- 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