No subject

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

> If we
> define the rules carefully so that $<> protects internal quotes then
> we can go back to the if/then/else approach I previously discarded:
> 
>   "$<IF 'cond-expr' 'then-expr' 'else-expr'>"
> 

You mean an evolution of this?

http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3615/focus=3756

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?

I think I can adapt the parser to that. 

That also means discarding the $<0:...> and $<1:...> basis for all of it, 
and possibly deprecating the use of ':' as a delimiter for the existing 
expressions like TARGET_FILE? I can probably do that in the parser too.

Thanks,

Steve.