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

Brad King brad.king at kitware.com
Thu Jun 9 08:25:40 EDT 2011


On 6/9/2011 2:58 AM, Alexander Neundorf wrote:
> This wish comes mainly from packagers, not from the developers themselves.
> I am sure packagers would be happy if they had one consistent way to disable 
> every package any cmake checks for with a standardized option.

This is a nice goal, but I do not think it is easy to do.

What if find_package(Foo) is called in more than one location with
different COMPONENT values?  What if one is required and the other is
not?  What if the FindFoo.cmake script calls find_package(Bar) and does
not require it but the project also does find_package(Bar) and does? I'm
sure there are more cases I haven't listed here.

The overall problem is that not all calls of find_package() are intended
to declare a dependency of the main project on a third party package.
In order to make such intention explicit you need to have a different
syntax, like a macro that handles it in a way that makes sense for a
given project.  When projects start nesting inside one another I'm not
even sure it is a well-defined problem.

>   if (! mf->IsOn(DISABLE_FIND_PACKAGE_<name>)
>   {
>     cacheVars = getAllCacheVars();
>     doNormalFinding();
>     newCacheVars = getAllCacheVars();
>     addedCacheVars = newCacheVars - cacheVars;
>     FIND_PACKAGE_<name>_CACHE_VARS = addedCacheVars;
>     put FIND_PACKAGE_<name>_CACHE_VARS in the cache
>   } 
>   else // it is disabled
>   {
>     get FIND_PACKAGE_<name>_CACHE_VARS from cache
>     remove all variables listed there from cache
>     set <name>_FOUND to FALSE
>   }

That kind of auto-cache-cleanup logic will be problematic in non-toy
cases.  If two different find_package() calls lead transitively to
the same cache values then one could erase the other's results.

-Brad



More information about the cmake-developers mailing list