[cmake-developers] Adding argument "OPTIONAL" to find_package() and add_subdirectory

[Alexander Neundorf]

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 this as a built-in feature to
> > find_package(), i.e. add a argument OPTIONAL to find_package(), then
> > probably also a "COMMENT".
> 
> The interface to find_package is already extensive.  This feature would
> have to come with a whole bunch of other options to control the name of
> the variable to match project conventions, etc...and none of these has
> anything to do with actually finding the package.  These features belong
> in project-specific macros, or simply
> 
>   option(USE_FOO "Enable features that require FOO")
>   if(USE_FOO)
>     find_package(FOO)
>   endif()
> 
> which IMO is more readable anyway.

It is 4 lines of cmake code to write instead of 1.
If this is done for several find_package() calls in a row this adds up.
Having such an option built-in would also hint the developer what the 
recommended way to disable packages is. 
E.g. with configure-scripts there is usually a --disable-foo switch.
With cmake this is completely up to the developers how to do it.

Having such an option for find_package() could establish such a standard way 
how to disable a library/package in cmake-projects.

Additionally, the four lines are not enough.
Later on in the CMakeLists.txt there are usually checks whether FOO has been 
found.
So at least FOO_FOUND has to be reset to FALSE, so a minimal version would be:

option(USE_FOO "Enable features that require FOO")
if(USE_FOO)
    find_package(FOO)
else()
   set(FOO_FOUND FALSE)
endif()

It also happens that developers test e.g. for FOO_LIBRARY etc.

Which makes the macro currently look like the following:

macro(_MOFP_SET_EMPTY_IF_DEFINED _name _var)
   if(DEFINED ${_name}_${_var})
      set(${_name}_${_var} "")
   endif(DEFINED ${_name}_${_var})

   string(TOUPPER ${_name} _nameUpper)
   if(DEFINED ${_nameUpper}_${_var})
      set(${_nameUpper}_${_var}  "")
   endif(DEFINED ${_nameUpper}_${_var})
endmacro(_MOFP_SET_EMPTY_IF_DEFINED _package _var)


macro (MACRO_OPTIONAL_FIND_PACKAGE _name )
   option(WITH_${_name} "Search for ${_name} package" ON)
   if (WITH_${_name})
      find_package(${_name} ${ARGN})
   else (WITH_${_name})
      string(TOUPPER ${_name} _nameUpper)
      set(${_name}_FOUND FALSE)
      set(${_nameUpper}_FOUND FALSE)

      _mofp_set_empty_if_defined(${_name} INCLUDE_DIRS)
      _mofp_set_empty_if_defined(${_name} INCLUDE_DIR)
      _mofp_set_empty_if_defined(${_name} INCLUDES)
      _mofp_set_empty_if_defined(${_name} LIBRARY)
      _mofp_set_empty_if_defined(${_name} LIBRARIES)
      _mofp_set_empty_if_defined(${_name} LIBS)
      _mofp_set_empty_if_defined(${_name} FLAGS)
      _mofp_set_empty_if_defined(${_name} DEFINITIONS)
   endif (WITH_${_name})
endmacro (MACRO_OPTIONAL_FIND_PACKAGE)


> > 2) we have something similar for add_subdirectory(),
> > macro_optional_add_subdirectory().
> > The purpose is to disable parts of a big project by skipping the
> > add_subdirectory.
> > 
> > This is a wrapper around add_subdirectory(), but adds an option
> > BUILD_FOO, which is enabled by default.
> > If disabled, the actual add_subdirectory() is not executed.
> > Additionally there is an additional global option
> > DISABLE_ALL_OPTIONAL_SUBDIRECTORIES, which is disabled by default.
> > If enabled, all these optional subdirectories are disabled (but can be
> > enabled again one by one).
> > 
> > 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.

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.

Alex