[cmake-developers] target_link_libraries, IMPORTED targets and SYSTEM includes

Stephen Kelly steveire at gmail.com
Tue Sep 10 12:20:49 EDT 2013


Brad King wrote:

> On 08/30/2013 06:49 AM, Stephen Kelly wrote:
>> I've pushed the IMPORTED-target-SYSTEM-includes topic to my clone for
>> review.
>> 
>> It introduces a policy-controlled default handling of
>> INTERFACE_INCLUDE_DIRECTORIES from IMPORTED targets as SYSTEM. It also
>> introduces a default-initialized target property to get the opposite
>> behavior in the cases where that is wanted.
> 
> The wording in the warning is a bit confusing:
> 
> +              "property.  This will not cause the contents of the
> property "
> +              "to be treated as system includes.";
> 
> As someone used to the old behavior I would read this and think
> "Why are you warning me that nothing is changing?".

Ok, I'll see if I can do better later.

> BTW, the policy number jumps to CMP0027.  This should be renumbered
> if no other policies are introduced first.

Yes. 

The export-policy branch in next introduces CMP0024.

The target-LOCATION-policy branch in my clone introduces CMP0025. I can't 
merge that to next until export-policy is in or as good as in. Otherwise I 
might have to change export-policy and have conflicts I'd prefer to avoid.

The double-colon-is-imported branch in my clone introduces CMP0026. I didn't 
complete that one yet because the two branches above need to go in serially 
first. 

I also haven't added tests to IMPORTED-target-SYSTEM-includes yet because 
it's less to re-number if things change between now and when I can merge it 
to next.

> 
> OTOH, this policy will trigger on every target that links to libraries
> providing usage requirements.  At most this is a difference between
> -I and -isystem which affects compilation only in incidental ways.

Yes.

> 
> Do we really need a policy?  Without one, projects will magically
> start building with fewer unnecessary warnings.

I'm fine with not controlling this with a policy. An abundance of caution 
led me to introduce one for it, but I'll happily remove it.

Thanks,

Steve.





More information about the cmake-developers mailing list