[cmake-developers] Interface includes and defines plumbing

Brad King brad.king at kitware.com
Fri Jan 4 11:49:55 EST 2013


On 01/04/2013 09:26 AM, Stephen Kelly wrote:
> Brad King wrote:
>> 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.

That goes through GetSOName which goes through ComputeImportInfo which
honors the mapping.  All target file location info is already handled
this way.  Looking through cmGeneratorExpressionEvaluator.cxx in your
branch I think everyplace is mapped that should be.

> 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

Hmm...actually $<CONFIG_DEBUG> should evaluate to true or false based
on whether the mapped configuration was considered a debug configuration
according to the exporting project's DEBUG_CONFIGURATIONS property.
Yuck.  Previously all export properties were generated by evaluating
each configuration of the exporting project and recording the results
at export time.  Now the configuration isn't used for evaluation until
loaded by the importing project.

One solution is to convert $<CONFIG_DEBUG> at export time to something
like $<OR:$<CONFIG:Debug1>,$<CONFIG:Debug2>,...> where Debug1;Debug2;...
are the values of the DEBUG_CONFIGURATIONS global property.  Another
solution is to use the $<OR:...> approach instead of $<CONFIG_DEBUG>
altogether.

Anyway, since $<CONFIG_DEBUG> is not part of this topic it doesn't yet
matter anyway.  The topic that adds it should be based on this topic
so it can get the config map handling.

> If, you agree, I'll merge this to next.

Yes, please.  Thanks for splitting this out.

-Brad



More information about the cmake-developers mailing list