Brad King wrote: > On 01/04/2013 08:39 AM, Stephen Kelly wrote: >> Stephen Kelly wrote: >> >>> Brad King wrote: >>>> * In the "Use mapped config properties to evaluate $<CONFIG>" you add >>>> code >>>> to handle MAP_IMPORTED_CONFIG. I think that should be an API on >>>> cmTarget refactored from its existing imported config selection code. >>> >>> You mean you want the $<CONFIG:mappedCfg> expression to depend on >>> whether LOCATION_mappedCfg exists, as the logic in ComputeImportInfo >>> requires? >> >> Done now, I think. > > Yes. For any given imported target a specific imported configuration > must be chosen to correspond to each of the current project's configs. > I think any place that uses context->Config needs to map it through > this lookup, not just $<CONFIG:...>, right?
Perhaps. There are existing uses in master (For TARGET_SONAME_FILE etc) which could possibly go through the mapping. I don't think that needs to block this topic though. The other uses of context->Config is in $<CONFIGURATION>, where I don't think the mapping should be used, and CONFIG_DEBUG, which you said previously should not use the mapping. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5398/focus=5488 If, you agree, I'll merge this to next. 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
