[cmake-developers] Target usage requirements and conventions

[Alexander Neundorf]

On Saturday 05 May 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > On Wednesday 02 May 2012, Stephen Kelly wrote:
> >> Brad King wrote:
> > ...
> > 
> >> > to mean find-if-necessary.  Then arguments after "Bar" would be
> >> > passed to the implied find_package for version and all the other
> >> > options.  Either Module mode or Config mode could detect whether
> >> > there is enough information to define the Bar package, and then
> >> > do so.  See below.
> >> > 
> >> > This brings up a fundamental question for this design discussion.
> >> > Are usage requirements associated with packages, with targets, or
> >> > with either/both?
> >> 
> >> Both, I think. They are associated with targets because properties on
> >> targets are what needs to be propagated as required for usage, and
> >> because targets will get usage requirements from other targets.
> >> 
> >> They are associated with packages for compatibility with packages which
> >> do not create exported targets, but which do have conventional prefixes
> >> on variables.
> > 
> > Going one step back: why is the package mode then necessary at all ?
> > If it is for packages which don't create imported targets, can't the
> > VARIABLE_PREFIX mode be used then ?
> 
> If a package does not define imported targets and does not use variables
> with a consistent and conventional names, then finding the PACKAGE mode is
> indeed not useful, I think.
> 
> The FIND_PACKAGE mode would find the package of the specified name, if we
> can agree on doing that and the exact syntax for it.
> 
> That seems to be the point that there is disagreement on currently though
> indeed.

I like your proposal very much for (imported) targets.
For (imported) targets it's clear what it is good for and how it is supposed 
to work.

OTOH the package-mode and variable-mode are IMO not necessary.
While for the variable-mode the behaviour is still quite clear, for the 
package mode there are many issues which are not obvious. What to do with 
multiple components, or one component and multiple libraries, search paths, 
required versions, etc.

If a package wants to support the new feature, it can install exported targets 
and set the appropriate properties.
If not, then users will continue to use the ${FOO_INCLUDE_DIRS} and 
${FOO_LIBRARIES} variables. I think that's fine.

Alex