[cmake-developers] conditionals in generator expressions

[Stephen Kelly]

Brad King wrote:

> On 05/25/2012 05:18 PM, Stephen Kelly wrote:
>> By the way, another thing we would need to cover with this is linking to
>> another library based on the value of a property.
>> 
>> https://codereview.qt-project.org/#change,26577
> 
> That one doesn't have to be delayed until generation time, but if we
> did have generate-time conditionals they could be used for this.

I was thinking about cases like this:

add_executable(Foo ${Foo_SRCS})

# ... Later
get_target_property(is_win_exe Foo WIN32_EXECUTABLE)
if (is_win_exe)
  # ...
endif()

# ... Later
set_target_properties(Foo PROPERTIES WIN32_EXECUTABLE True)

I'd like to know the final content of the property, so that I can link the 
static lib in if required.

> We're in agreement that this is turning into a declarative spec.

I thought about this some more and I think I don't understand what you mean 
by this. Do you mean that the contents of the generator expressions should 
be declarative expressions?

> If we keep the evaluation of it at generate time then there is no
> chance that imperative logic will conflict because the imperative
> part runs only during the configuration step.
> 
>> I thought maybe we can discard the idea of using generator expressions
>> built into the property content, and introduce a new finalize() command
>> similar to macro() and function():
> 
> It would have to run once for each configuration to be generated
> and receive said configuration as an argument.  The implementation
> would have to fork the entire representation into independent
> per-configuration branches (cmMakefile, cmTarget, etc.).  It would
> also allow imperative logic after the end of configuration or during
> generation time which should be avoided for the reason above.

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.

Depending on what you meant regarding declarative specification here 
(http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3615/focus=3768), 
it might be that we haven't found the right idea yet, and we need some more 
ideas. 

I had another idea inspired by javascript, which allows calling any function 
with a different 'this' object (ie, a functional spec rather than 
declarative):

generator_expression(myGenExpr)
  # The target this expression is called on is available with the
  # alias 'this_Target'. The configuration is available with the 
  # alias 'this_Config' (or this_BUILD_TYPE, or ...).
  # Maybe 'this_VARIABLE_SCOPE' could be used to determine whether we're 
  # populating a variable for PUBLIC consumption (from imported 
  # targets later), or just for use while building this target.
  if (this_Config STREQUAL "COVERAGE")
    generate_resolved("/foo/bar") # This command is like 
        # 'return'. No further commands in this generator_expression
        # are executed 
  endif()

  if (this_Config STREQUAL "RELEASE")
    get_target_property(propValue this_Target SOME_SPECIAL_PROP)
    # We can't set properties on the target in a generator_expression.
    if (propValue)
      generate_resolved("/migs/mags")
    endif()
  endif()

  if (this_Config STREQUAL "DEBUG")
    set(resolvedStuff)
    if (BUILD_TESTING)
      list(APPEND resolvedStuff "/blip/")
    endif()
    if (LANGUAGE STREQUALS "CXX")
      list(APPEND resolvedStuff "/boog/")
    endif()
    generate_resolved(resolvedStuff)
  endif()
  # Implicit generate_resolved("")
end_generator_expression()

add_library(Foo ${Foo_SRCS})
set_property(TARGET Foo APPEND 
    PROPERTY "/bing/trog;$<GENERATOR:myGenExpr>;/ming/mong"
)

The $<GENERATOR:someName> could similarly be used for defines and other 
places where we are discussing adding this feature. 



I don't know if there's any reason the language can't or shouldn't be used 
in this way (it may lead to some odd rules about when 
${Qt5WinMain_LIBRARIES} is resolved for example), but it seems we still need 
ideas on how to make this whole target orientation concept work. 

Thanks,

Steve.