[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