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