[cmake-developers] How to handle package Config.cmake files with dependencies ?

[Alexander Neundorf]

On Monday 27 February 2012, Brad King wrote:
> On 2/27/2012 3:37 PM, Michael Wild wrote:
> > On 02/27/2012 09:15 PM, Alexander Neundorf wrote:
> >> When the FooConfig.cmake has been found, Foo_FOUND is set to TRUE:
> >>   // Set a variable marking whether the package was found.
> >>   
> >>    std::string foundVar = this->Name;
> >>    foundVar += "_FOUND";
> >> 
> >> This means it is true in all cases that the Config.cmake file has been
> >> found (and the version was compatible).
> 
> The find_package command is acting as a primitive like find_library from
> the point of view of setting Foo_DIR, and that can be tested directly to
> see if the config file was found.  That leaves room to change the way
> we set Foo_FOUND.  We could add a policy that in NEW behavior unsets
> Foo_FOUND completely before loading FooConfig.  After FooConfig has been
> loaded it detects whether Foo_FOUND is now defined.  If set, use that
> value.  If not set, set it to true as it is now.  That will give the
> FooConfig file a chance to set the result.

Sounds good.
Do you think that needs a policy ?
The code currently does:

  // Set a variable marking whether the package was found.
  std::string foundVar = this->Name;
  foundVar += "_FOUND";
  this->Makefile->AddDefinition(foundVar.c_str(), found? "1":"0");

(I forgot the last line in my initial mail).
So the variable is set afterwards unconditionally.
The only condition where it would make a difference is if inside a 
FooConfig.cmake file there would be a check whether Foo_FOUND is already TRUE.

I can do that.

> >> * how to handle COMPONENTS ?
> > 
> > I like that proposal. I'm also quite unhappy with how components are
> > handled in config-mode.
> 
> With the approach I suggest above it will be up to FooConfig to determine
> this.
> 
> Another approach is to add an API to give FooConfigVersion access to the
> list of desired components.  If the package version file encodes a known
> list of available components it would be able to report UNSUITABLE if a
> requested component is missing.  Then find_package would move on to
> another candidate.  This might confuse users that expect a particular
> location to be found because it wouldn't report that it is missing a
> component and instead silently ignore it.  It is probably better to let
> FooConfig report a message that says its Foo doesn't have the component.

Yes, I agree that putting the component-handling into the version file sounds 
a bit unexpected.
 
Alex