[cmake-developers] Setting target properties before the target is defined ?

[Brad King]

On 02/17/2013 10:26 AM, Alexander Neundorf wrote:
> On Sunday 17 February 2013, Alexander Neundorf wrote:
>> On Sunday 17 February 2013, Brad King wrote:
>>> to use a directory property and then have the generate-time check
>>> look in the current directory and up.  That will avoid problems with
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> scoping of the variable if the project loads the file from inside
>>> a function scope.
>>
>> Oh, right, from inside a function scope...
> 
> But directory properties don't propagate into subdirs.

That's why I included the "in current directory *and up*" in the proposal.

> Now, there is the GLOBAL keyword for imported targets, so they can be used 
> anywhere.

Actually that's another reason to delay the diagnostic until generate
time.  A target with the GLOBAL option could become visible anywhere
else in the project, not just by the end of the current directory.

> Just put everything into a GLOBAL property ?
> Can this lead to problems ?
> I think only in the case of name clashes.

Yes, so a GLOBAL property will not work.  We need something with the same
scope as imported targets.

> Using a cmake variable a failure would mean the project fails at build time 
> instead of at cmake time.
> 
> So, how about the following:
> * if it's a GLOBAL imported target, put the required imported libs into the 
> directory property of ${CMAKE_SOURCE_DIR}

If the target is missing how do we know if it would have been global or not?

> * at generate time, generate once for each directory a vector of expected 
> imported targets by inheriting the property from the parent directories down 
> to the subdirectories

As I said above the generate-time check can look in the current directory
and up.

> * check those accumulated directory properties in FindTargetToUse() 

It should only matter in a call looking for the target when evaluating
the link interface of an imported target.  That will be *a* call to
FindTargetToUse but other calls won't care about this.

Another approach is to just add an extra property to imported targets
that list their dependencies that are expected to be targets.  If when
following the link interface out of that target and a library name is
not a target, check the extra property on the very same target to see
if it should have been one.

-Brad