On 06/05/2012 04:59 PM, Stephen Kelly wrote: > So far we don't have agreement about how this should look language-wise as > far as I can tell. I agree with David that stuffing it into the strings > harms readability. [snip] > generator_expression(myGenExpr) [snip] > The $<GENERATOR:someName> could similarly be used for defines and other > places where we are discussing adding this feature.
That is an interesting idea to keep in mind for the future but I think the implementation of it is too tricky to be in scope now. David Cole and I met this morning to try to resolve this issue. We've come up with a fairly simple and acceptable solution for conditionals in generator expressions. The idea is to define a set of simple, easy-to-parse expressions that together allow what we need. Start with two expressions with constant behavior: $<0:...> evaluates to empty string, always $<1:...> evaluates to ... string, always The "0:" and "1:" are literal and may not be anything else. The "..." is arbitrary content except for '>'. On their own, these are not very helpful, but now add some condition tests: $<CONFIG:...> evaluates to 0 or 1 if config matches ... $<LANGUAGE:...> evaluates to 0 or 1 if language matches ... $<TARGET_PROPERTY_BOOL:WIN32_EXECUTABLE,tgt> = 0 or 1 Each conditional test evaluates to exactly "0" or exactly "1". Internally each allows only very restricted syntax (as in C identifiers for potential config names, etc.). Finally, add boolean combinations: $<AND:x,x,x,...> evaluates to 1 if all x=1, else 0 $<OR:x,x,x,...> evaluates to 0 if all x=0, else 1 $<NOT:x> evaluates to 1 if x=1, else 0 where all instances of "x" must be exactly "0" or "1". Combinations of the above expressions will do what we need: $<$<CONFIG:Debug>:/path/for/Debug> $<$<NOT:$<CONFIG:Debug>>:/path/for/non-Debug> $<$<AND:$<CONFIG:Debug>,$<LANGUAGE:CXX>>:/path/for/Debug/Cxx> Each individual expression is easy to define, document, and implement. Each has a very strict syntax we can validate as part of the implementation and parsing, thus allowing future extensions. They look like existing generator expressions and follow a functional style. Comments? -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