Brad King wrote: > On 08/22/2012 06:12 PM, Stephen Kelly wrote: >>> of linking there are multiple targets involved so we do not know >>> which one the user may mean. >> >> I think it's something we can just define, is it not? > > Some expressions might want the target being linked while others may > want the target in which the expression is specified. Both are > possible within a single evaluation. Something like $<LINK_TARGET> > could expand to the name of the target being linked in order to allow > that to be specified as the target to look at.
Yes, I can see how the language could be able to offer both. However, I do think that the built-in 'this' target should be the one that the generator expression is evaluated on. In the future, we'll want to do things like this: # The INTERFACE_LIBRARY target type doesn't have anything to build, but # is a 'container' object for INTERFACE properties. add_library(foo INTERFACE) set_target_properties(foo PROPERTIES # (Simplifying the generator expressions for brevity) LINK_INTERFACE_LIBRARIES "bar;$<$<TARGET_PROPERTY:WIN32_EXECUTABLE>:bat>" INTERFACE_INCLUDE_LIBRARIES "$<$<TARGET_PROPERTY:TYPE,EXECUTABLE>:/baz/>" INTERFACE_COMPILE_DEFINITIONS "..." ) add_executable(myexe) target_use_targets(myexe foo) Such INTERFACE_INCLUDE_DIRECTORIES could be useful for header-only libraries for example. In that context, having the 'this' target be 'the target on which the user actually set the property with the generator expression' doesn't make sense. The above also I think reinforces the existing idea that INTERFACE properties are really just information for the consumer of the target, rather than something tied to the target they are set on. > >>> In (5) you need to delay evaluation of generator expressions as >>> long as possible, essentially until the computation of the final >>> link line for a specific target. >> >> Yes. Only the content of LINK_INTERFACE_LIBRARIES needs to be treated >> that way though. > > For STATIC libraries there is no LINK_INTERFACE_LIBRARIES. The > the libraries given to target_link_libraries *are* the link interface. Does this STATIC case change the above logic in some way? >> Finding out what new generator expression conditions are needed might >> also fit. I'm not certain about the TARGET_PROPERTY_BOOL and >> TARGET_PROPERTY_STREQUAL. I think it might be better to introduce >> $<BOOL:...> $<STREQUAL:lhs==rhs> and $<TARGET_PROPERTY:prop> and then be >> able to use eg: >> >> $<$<BOOL:$<TARGET_PROPERTY:WIN32_EXECUTABLE>>:Qt::WinMain> >> >> $<$<STREQUAL:$<TARGET_PROPERTY:TYPE>==EXECUTABLE>:QtFoo> > > Now *that* is starting to look like a functional language :) The STREQUAL expression also makes the CONFIG expression redundant and equivalent to $<STREQUAL:$<CONFIGURATION>,...>. I can see reason to keep CONFIG anyway because it is more convenient and is expected to be commonly used I think. > > It is a more general approach, but we need to define the > parsing and evaluation in a better way than it is now. I've pushed a generator-expression-refactor branch to my clone. It needs some clean-up, de-duplication etc, but I'm looking for feedback on the approach. > What > if the referenced $<TARGET_PROPERTY:FOO> has a value containing > "=="? In my branch, all parameters must be separated by ','. All commas and colons must appear literally in the expression. This makes escaping not-needed, and multiple-parameter-separators consistent accross all generators. > We need the expression processor to support some kind of > escaping/quoting syntax and lazy evaluation. The STREQUAL test > needs to be able to parse its arguments "$<TARGET_PROPERTY:TYPE>" > and "EXECUTABLE" first and evaluate them recursively. Done in the branch. Let me know what you think. 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
