[cmake-developers] Interface includes and defines plumbing

[Stephen Kelly]

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.