[cmake-developers] conditionals in generator expressions

Brad King brad.king at kitware.com
Thu Aug 30 13:47:47 EDT 2012


On 08/30/2012 11:55 AM, Stephen Kelly wrote:
> From earlier:
>> One way to distinguish expressions with free-form arguments from
>> those without is whether there is a ':' or whitespace after the
>> expression name.
> 
> This isn't very clear to me. Should ':' be part of the syntax which is 
> always needed? Or only needed in disambiguation cases? I'm not in favor of 
> syntax which is only used in a small subset of expressions only for 
> disambiguation. 
> 
> If ':' must appear after the expression name sometimes, then it should have 
> to be there all the time.

It is a way to disambiguate for compatibility with the existing expressions
while still allowing them to be used with the new syntax if we want.  IMO

 $<TARGET_FILE:myexe>

is more readable than

 $<TARGET_FILE 'myexe'>

but we could support both and let the user decide.  We could simply say that
the "$<EXPR_NAME:...>" form is equivalent to "$<EXPR_NAME '...'>" treating
all the content after ":" as one argument.

> You mean an evolution of this?
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3615/focus=3756

Yes.

> So if we reintroduce IF, we'll en up with something like this:
>  
> 1)  "$<IF $<CONFIG Release> /rel/ease /de/bug>"
> 
> 2)  "$<IF $<BOOL $<TARGET_PROPERTY WIN32_EXECUTABLE> > Qt5::WinMain>"
> 
> 3)  "$<IF $<BOOL $<TARGET_PROPERTY"
>         "WIN32_EXECUTABLE> > Qt5::WinMain>"
> 
> 4)  "$<IF $<BOOL $<TARGET_PROPERTY
>         WIN32_EXECUTABLE> > Qt5::WinMain>"
> 
> 5)  "$<IF $<AND 
>               $<BOOL $<TARGET_PROPERTY WIN32_EXECUTABLE> >
>               $<STREQUAL $<TARGET_PROPERTY TYPE> EXECUTABLE> >
>           Qt5::WinMain>"
> 
> ?
> 
> I guess 3 won't work, but 4 would be used instead?

Yes.

> I think I can adapt the parser to that. 

Before jumping into the code please try to construct a formal grammar
for discussion.  That will split review of the code from review of
the grammar.

> That also means discarding the $<0:...> and $<1:...> basis for all of it

I'm fine with that since it hasn't been released yet anyway.
They are not mutually exclusive though.  My above definition
of the ":" behavior still allows it.  In the case of AND/OR/NOT
the single argument would be parsed inside their evaluation to
extract the "0" "1" and "," pieces.

-Brad



More information about the cmake-developers mailing list