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