[cmake-developers] Interface includes and defines plumbing
Stephen Kelly
steveire at gmail.com
Mon Jan 7 15:36:50 EST 2013
Brad King wrote:
> On 01/07/2013 02:50 PM, Stephen Kelly wrote:
>> I've pushed two new branches to my gitorious clone.
>>
>> include-dirs-convenience
>>
>> For the same reason that CMAKE_INCLUDE_CURRENT_DIR exists, but for
>> interfaces. Please let me know what you think about the idea and API.
>
> The CMAKE_BUILD_INTERFACE_INCLUDES approach looks good. The name
> reserves room for other auto-BUILD_INTERFACE values in the future.
Great.
>
> The install-tree equivalent is a neat idea. Upon first reading the
> test call with "INCLUDES DESTINATION" I wasn't sure whether it was
> trying to install some kind of "associated headers" list or something.
Yes, I have the same concern. It's not like the other DESTINATION components
of the command, which actually install what they say (includes in this case)
to the destination.
> Perhaps the word "INTERFACE" should appear here to make sure it is
> clear that it is setting an interface on the installed target.
Perhaps it should be
install(TARGETS testLibRequired
EXPORT RequiredExp DESTINATION lib
INTERFACE_INCLUDES
"/foo/bar"
)
?
> I
> wonder if we should hold off on this convenience interface until more
> of the new usage interface magic is worked out. We may be able to
> find an even more convenient way to set a whole bunch of stuff on
> an installed target's interface.
Ok. I can split CMAKE_BUILD_INTERFACE_INCLUDES into a topic of its own.
>
>> target-includes-defines-commands
>>
>> For primary population of interface and non-interface includes and
>> defines. The target_include_directories command will also be useful to
>> 'correct' the order of includes in the future when that is done at the
>> same time as link libs population.
>
> It looks like the signatures have exactly one visibility keyword.
> Shouldn't they allow the keyword to be repeated so that the entire
> internal and external values can be specified in a single command?
Yes, I can modify it to that effect. I was also thinking that for the
includes command it might make sense to have a BEFORE keyword, but I'm not
certain.
I also have a slight concern that
target_compile_definitions(foo PRIVATE bar)
has an ambiguous meaning.
It could mean 'take the INTERFACE_COMPILE_DEFINITIONS from the bar target
and use them' or it could mean 'Add -Dbar to the COMPILE_DEFINITIONS',
depending on whether a target called 'bar' exists.
The workaround is to use set_property in that case.
target_include_directories does not have that problem, as paths must be
absolute.
What do you think?
> The new commands do not need to be included in the bootstrap build.
> We won't be using them in CMake's own rules for a while.
Ok.
Thanks,
Steve.
More information about the cmake-developers
mailing list