[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