[cmake-developers] target_include_directories() accepts only absolute paths ?

Stephen Kelly steveire at gmail.com
Tue Jan 29 10:25:29 EST 2013


Brad King wrote:

> On 01/29/2013 04:23 AM, Stephen Kelly wrote:
>>>> that tll() will handle linking completely and partly setting up the
>>>> includes.
>> 
>> I'm not sure what you mean by 'partly'.
> 
> I think Alex meant that plain directories cannot be added with tll for
> includes.  However, we have to be careful not to mix up configuration of
> the target's own build requirements versus propagation of requirements
> from dependencies.  The former should still use tid and tcd while the
> latter will now be fully handled by tll.

Yes.

> 
>>> What if only tll continues to allow raw target names and tid and tcd
>>> assume non-target without using a generator expression?  In the common
>>> use case tll will now do linking/includes/defines for targets anyway so
>>> we will need tid and tcd only for real raw dirs/defs.
>> 
>> Yes, I think that's right.
>> 
>> As a somewhat real-world use of this stuff, see this patch to the kde-
>> frameworks branch:
>> 
>>  http://www.steveire.com/0001-wip-remove-redundant-include_directories-
calls.patch
> 
> Nice!
> 
>> So, the conclusion is that we can remove target handling from
>> target_compile_definitions and target_include_directories entirely?
> 
> Yes, especially if it works for your real-world case.  Whenever one
> really wants to use a target one can use the plumbing directly:
> 
>  $<TARGET_PROPERTY:mydep,INTERFACE_INCLUDE_DIRECTORIES>

Yes that's fine. We could add a TARGETS keyword to the new commands, but as 
that would be about usage-requirements propagation - which we want to 
specify using tll instead - I don't think we need to do that.

> 
>> Should we wait for the conclusion of the upstream/downstream/policy
>> issue in the other thread?
> 
> Aren't these issues orthogonal (other than merge conflicts)?
 
Yes, I don't really know why I wrote that. Maybe only because of the merge 
conflicts issue.

I guess it would be easier to have what is in next merged to master or 
removed (interface-commands-lazy-target-check) so that we can start with a 
clean slate and see what's left. fix-relocatable-include-dirs is a potential 
source of conflict with what we've been discussing.

Thanks,

Steve.





More information about the cmake-developers mailing list