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

[Brad King]

On 6/9/2011 8:50 AM, Alexander Neundorf wrote:
> Calling FindQt4 in some directory with components A and B, and in some other 
> directory with component C, and the second one doesn't do anything because the 
> first one has already set something to "I am done" already so the second one 
> doesn't do anything.

Yeah, that's a per-package implementation detail which is not
well-handled in all the scripts.

> Maybe we have the same issue when somebody calls
> find_package(Foo 2.0.0 NO_MODULE)
> in some directory, and it finds eg. version 2.0,
> and
> find_package(Foo 3.0.0 NO_MODULE) 
> in some other directory ?
> Foo_DIR (which is in the cache) has been already set then.
> This could be also mixed with different components, which may are only 
> installed for one of the two versions...

Yes, but this is not the same as finding the same version twice with
different options.  Mixing third-party dependency versions within the
same project is hard for more reasons than this.

>> 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.
> 
> I think this can be handled.
> find_package() should error out in this case, because Bar was required but it 
> was disabled.
> Maybe this option to disable a find_package() could even be provided for all 
> find_package() calls, and for each REQUIRED one it will cause an error. This 
> would create a bunch of unusable options, but would be very consistent ;-)

Okay.  However, the option does not need to be "provided" as a
gui-settable value for packagers to be able to disable things from build
scripts.  The command could honor the value if it is present but not
advertise it.

>> 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.
> 
> Are you sure ?

I think there will be all kinds of interactions that we cannot predict
leading to mysterious hard-to-find behavior.  The stated goal of this
feature is for packagers to disable things.  That does not require any
action when the state of an option changes because packagers use
one-shot build scripts.

-Brad