[cmake-developers] Setting includes, defines and other usage requirements with one command

Stephen Kelly steveire at gmail.com
Mon Feb 11 13:15:11 EST 2013


Brad King wrote:

> On 02/08/2013 04:56 PM, Brad King wrote:
>> On 02/08/2013 03:16 PM, Stephen Kelly wrote:
>>> My preference currently is to leave things as they are including the
>>> long and useless string.
>> 
>> Your analysis is quite extensive, thanks.
> 
> I thought about this more over the weekend.  I think we've made this much
> harder than it needs to be.  One of the main arguments for propagating
> includes and defines through tll() is that all other usage requirements
> like -fPIC will now be able to propagate through it too.  However, why
> don't those usage requirements turn into complex interface properties like
> those we've been discussing for includes/defines?  It's because they are
> not applied until generation time.

Yes, but also because it's a boolean, not a list which must be uniq'd.

> Ordering does not matter for compile definitions.  Ordering does matter
> for includes, but the reason we added <package>_NO_INTERFACES was due
> to tll() changing the order for existing projects.  I think it will be
> much simpler to have usage requirements of all types simply appended
> to the settings configured by the project:
> 
> * Link libraries already work this way
> 
> * Compile definitions order does not matter
> 
> * Include directories order matters sometimes, but in cases the order
>   generated by appending usage requirements fails the project can
>   simply use tid() with $<TPROP:foo,INTERFACE_INCLUDE_DIRECTORIES>
>   themselves.  Furthermore since the usage requirements always append
>   there is no compatibility issue for upstreams adding include dirs
>   so we may not need <package>_NO_INTERFACES.

So GetIncludeDirectories() would be changed to generate the directories in 
this order:

 * The content of the INCLUDE_DIRECTORIES property
 * The INTERFACE_INCLUDE_DIRECTORIES of linked targets

Correct? I think that would work, but implementation-wise, tll() will still 
populate some structures on the cmTarget for the includes anyway to keep 
track of backtraces. Those won't be exported though. The behavior may also 
be a little difficult to document because the result of the tll is always to 
append no matter the order of it relative to other calls:

 include_directories(/foo/bar)
 target_link_libraries(tgt other)
 include_directories(/bing/bat)

That's really just a documentation concern. As there is no backward 
compatibility concern, I'm sure it's fine.

> 
> This approach will drop all the complex generator expressions from
> the interfaces altogether.  Only the expressions written by the
> user will ever be needed.  For non-target library names passed to tll()
> there is no issue because at generate time we will know they are not
> targets.

Yes, we won't even need to know at export-time, because the generator 
expressions will have been already evaluated. 

So, I think this is a good idea. I can work on it after minor-fixes is 
merged probably. The only commit in there that is not needed is the one 
changing LINKED. You can rebase that away or create another branch and 
cherry-pick the following two commits or whatever other git incantation you 
wish. They've all already been through the dashboard anyway.


Thanks,

Steve.





More information about the cmake-developers mailing list