[cmake-developers] Target usage requirements and conventions

[Alexander Neundorf]

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 ?

> >>> We will likely need to make packages something first-class on the
> >>> C++ side.  If find_package(Bar) detects that the files it loaded
> >>> define sufficient information for a package it should construct a
> >>> C++ object to represent the package.  This event should establish
> >>> the package.  A loose sequence of variable set()s is not explicit
> >>> enough.
> >> 
> >> Right.
> > 
> > How might find_package detect/define a first-class package object?
> > Just look for the right variables?  Perhaps we could add an (optional)
> > 
> > explicit package declaration:
> >   cmake_package(Bar LIBRARIES ... DEFINITIONS ...)
> > 
> > that can be either in the Find module or in the package configuration
> > file.  This would allow more detailed information to be set.
> 
> Maybe. Where would this get us that convention in the right variables would
> not?
> 
> I can imagine someone looking at that and thinking that that's the way to
> notify users of my package/config file how to use it, and disregard the
> actual variable name conventions:
> 
> FooConfig.cmake:
> 
> set(THE_FOO_LIBRARIES foo1 foo2)
> 
> cmake_package(Foo LIBRARIES ${THE_FOO_LIBRARIES})
> 
> Then again, cmake_package could also ensure that the correct conventional
> variables are set by actually setting Foo_LIBRARIES to be the contents of
> THE_FOO_LIBRARIES in that case, ensuring the possibility of using the
> variables conventionally.
> 
> That also opens up the question of whether it should overwrite
> Foo_LIBRARIES if it already exists, or warn about that.
> 
> I also think the 'Foo' would be redundant. It should be this to avoid
> mistakes:
> 
> cmake_package(LIBRARIES ${THE_FOO_LIBRARIES})
> 
> CMake already knows the name of the package, right?

Isn't this getting a bit too much of new concepts ?
I mean, the semantics of target_use_package() with imported or in-project 
targets are quite clear.
Isn't everything else not maybe only added complexity for little benefit ?

Alex