[cmake-developers] exports and MAP_IMPORTED_CONFIG_<CONFIG>

[Stephen Kelly]

Brad King wrote:

> On 12/09/2012 08:48 AM, Stephen Kelly wrote:
>> I think the 'Setting include directories via target_link_libraries() ?'
>> thread needs to be concluded first (with reasoning), as that affects
>> everything else.
> 
> While thinking about my next response to that discussion I realized
> that most of our discussion so far about exported interfaces has missed
> a major piece.  You briefly mentioned it while we discussed the syntax
> of the $<CONFIG_DEBUG> expression.  It is MAP_IMPORTED_CONFIG_<CONFIG>:
> 
>  
http://www.cmake.org/cmake/help/v2.8.10/cmake.html#prop_tgt:MAP_IMPORTED_CONFIG_CONFIG
> 
> Every part of an exported interface (link interface libraries, include
> dirs, compile definitions, etc.) potentially depends on the configuration
> being exported from the project.  The exporting project knows nothing of
> the importing projects' configurations.  All evaluation of its generator
> expressions must be done using only one of the original configurations
> for expressions like $<CONFIG:...>, $<CONFIG_DEBUG> and $<CONFIGURATION>.

So, the problem is that upstream will populate interfaces for configs of its 
own choosing, and downstream is responsible for mapping to them?

So, upstream can contain this:

 $<$<CONFIG:Release>:foo>

and downstream can contain this:

 MAP_IMPORTED_CONFIG_COVERAGE "Release"

and that will be ignored by what is currently in the branch when downstream 
is using the COVERAGE config. 

I think that's correct, and I see the problem. 

I don't see any reason to change $<CONFIGURATION> in any way, but I see a 
reason for CONFIG and CONFIG_DEBUG to be changed to be aware of mapped 
configs. Is changing that ok from a backward compatibility point of view? Do 
we need a policy? 

> 
> One approach to this is to perform partial evaluation of all exported
> interfaces to resolve generator expressions that depend on the config.
> Then store the results in exported properties ending in _<CONFIG>.

Are you suggesting storing this stuff in new properties like 

 INTERFACE_LINK_LIBRARIES_DEBUG

etc? Ie new-style with a <CONFIG> suffix?

> This is essentially what CMake <= 2.8.10 does to produce properties
> like IMPORTED_LINK_INTERFACE_LIBRARIES_<CONFIG>, but that is actually
> full evaluation because there is no support for generator expressions.

My first thought would be to change the implementation of 
DebugTestNode::Evaluate instead to query the mapped configs from the 
context->Target, or context->WorkingTarget (which doesn't exist yet). 

Is there a reason to prefer partial evaluation and multiple exported 
properties in the _<CONFIG> style?

> The importing project then selects one of the exported configurations
> using heuristics and MAP_IMPORTED_CONFIG_<CONFIG> if defined.
> 
> Another approach is to try to honor the configuration mapping while
> evaluating exported generator expressions in the importing project.

Ah, I think this is what I suggest above too.

> Evaluation would need to track when it crosses into expressions that
> came from another project and lookup the configuration mapping.

According to 

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3737/focus=3751

config packages don't set MAP_IMPORTED_CONFIG_<CONFIG>, and only the caller 
does. Where would the configuration mapping come from is another project is 
encountered?

> 
> Note that the above holds for not only link interface libraries but
> for any new usage requirements support too.  For example in the partial
> evaluation approach the exported interfaces would need properties like
> 
>  (IMPORTED_)?INCLUDE_DIRECTORIES_<CONFIG>
>  (IMPORTED_)?COMPILE_DEFINITIONS_<CONFIG>
> 
> Such properties are distinct from properties like INCLUDE_DIRECTORIES
> in that they will not contain config-dependent generator expressions.

... but otherwise can contain generator expressions, which differentiates 
them from the old-style properties?

I prefer the approach of honoring the configuration mapping while evaluating 
the generator expression. That way we don't have to introduce _<CONFIG> 
variants for the new properties, which simplifies documentation at least :) 
'this one can use $<CONFIG>, but this one can't' etc.

Thanks,

Steve.