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. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers