[cmake-developers] Target usage requirements and conventions

[Stephen Kelly]

Brad King wrote:

> On 05/17/2012 09:25 AM, Stephen Kelly wrote:
>>>   "$<IF($<CONFIGURATION> MATCHES Debug AND $<LANGUAGE> STREQUALS
>>>   CXX)...>"
>>>
>>> I'm not sure what should go in the "..." part though.  Some syntax to
>>> delimit the then/else values would be needed.
>> 
>> I'm not sure else() and endif() are needed as additional expressions
>> could be added for those.
> 
> We may not need the "else" part but we still need a strict and extensible
> syntax to delimit the value in the "..." part above.

I guess you mean something like ENDIF won't be good enough. I guess it might 
not be extensible if you want to do something else than if...endif, but I'm 
not certain what you have in mind with 'extensible' or if you have any ideas 
of how it might need to be extended.

> 
>> Perhaps we can get object-orientated:
>> 
>> populate_target_usage_requirements(
>>   NAME fooRequirements
>>   [PUBLIC|PRIVATE]
>>   INCLUDE_DIRECTORIES "/foo/bar"
>>   INCLUDE_DIRECTORIES "/bat/bug" IF $<CMAKE_BUILD_TYPE> MATCHES Debug
>>   COMPILE_DEFINITIONS "-DQT_CORE_LIB"
>>   COMPILE_DEFINITIONS "-DQT_GUI_LIB" IF BUILD_TESTING
>> )
> 
> I think it will be hard to define the reach to the left of IF in
> non-trivial cases

ENDIF again no good here?

> , especially when the arguments are built up inside
> a variable and some parts might end up empty.  

You mean like this:

if (some_option)
  set(include_condition IF $<CMAKE_BUILD_TYPE> MATCHES Debug ENDIF)
endif()

populate_target_usage_requirements(
  ...
  INCLUDE_DIRECTORIES "/bat/bug" ${include_condition}
)

> Also the result of this
> command will still need to be stored in the property as some kind of
> generator expression, so we still need to define such an expression.

Yes. My idea is based on the properties with generator expressions not being 
so convenient to edit at runtime as in the example I gave before, but 
providing this API to wrap the less convenient 'generator containing a 
boolean expression' elements.

But indeed, this alone does not solve the problem of creating a strict 
enough syntax for storage of the properties.

Thanks,

Steve.