[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