[cmake-developers] exports and MAP_IMPORTED_CONFIG_<CONFIG>

[Brad King]

On 12/13/2012 08:44 AM, Stephen Kelly wrote:
> So, the problem is that upstream will populate interfaces for configs of its 
> own choosing, and downstream is responsible for mapping to them?

Yes.

> I don't see any reason to change $<CONFIGURATION> in any way

Hmm...I'm not sure about that one.  I'm inclined to think it should be mapped
too so that it evaluates the same way it would have in the exporting project.

> 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?

No CMake release supports generator expressions in exports yet so the
compatibility concern would be only for projects that hand-write imported
targets.  In that case they are probably using their own configs anyway.

> Are you suggesting storing this stuff in new properties like 
>  INTERFACE_LINK_LIBRARIES_DEBUG
> etc? Ie new-style with a <CONFIG> suffix?

In that approach, yes, but the second approach doesn't need it.

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

No, and it may not even be possible because things like $<TARGET_FILE:...>
may depend on the config but cannot be evaluated up front.

> 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.

Yes.

> Where would the configuration mapping come from is another project is 
> encountered?

The mapping comes from the MAP_IMPORTED_CONFIG_ on the target from which
the property value containing the current generator expression was read.
Perhaps you can fold this into the generator expression compilation
process.  Internally you could wrap the entire expression in the
equivalent of a scheme "let" block that binds the current config for
expressions inside it.

-Brad