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 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers