Brad King wrote: >>> It should be in cmTarget::ComputeLinkImplementation at this line: > > If it is not that early then we need to consider the interaction > of at least these pieces: > > cmTarget::GetLinkerLanguage > cmTarget::GetLinkClosure > cmTarget::ComputeLinkClosure > cmTarget::GetLinkImplementation > cmTarget::ComputeLinkImplementation > cmComputeLinkInformation > cmComputeLinkDepends > > They all deal with the link libraries and need the processed > output of generator expressions.
Thanks for the info. There is indeed a lot to look into for the link libraries part of theis feature. >> I tried this, but it made (5) below not work anymore. The generator >> expression was evaluated too early it seems for Qt5::Core, and at that >> point TYPE == SHARED_LIBRARY. > > Way back when we discussed the $<TARGET_PROPERTY_...> expressions > we concluded that the target could be implicit because they are > always evaluated in the context of a target. However, in the case > 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? We can say that in: target_link_libraries(foo $<EXP1> ) target_link_libraries(foo LINK_PRIVATE $<EXP2> LINK_PUBLIC $<EXP3> ) target_link_libraries(foo LINK_INTERFACE_LIBRARIES $<EXP4> ) EXP1 and EXP2 are evaluated only on foo. EXP3 is evaluated on foo, but also on any target that depends on foo, - either directly, or because of foo being included in the LINK_INTERFACE_LIBRARIES of another target. EXP4 is evaluated only on other targets but not on foo. This follows the same logic as the rules for linking. So, if we can document it as the same, we do know what the user means. > > 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. > The same expressions may be > evaluated multiple times in different contexts and yield different > results e.g. link Qt5::Core into a GUI and a non-GUI executable. Yes. > Delayed evaluation means we need to handle list expansion cleanly. > One approach is to try to re-work all the above-named methods to > keep the original link information in pure-string form instead of > performing ExpandListArgument early. The target_link_libraries > command would set a string-valued LINK_LIBRARIES target property > instead of recording some internal C++ structure, just like the > LINK_INTERFACE_LIBRARIES property. This conversion would be > similar to the INCLUDE_DIRECTORIES target property behavior we > recently introduced. Add an interface in cmGeneratorTarget to > evaluate generator expressions in the LINK_LIBRARIES and > LINK_INTERFACE_LIBRARIES properties given the context of some > target for which the final link library list is being computed. Yes, this sounds workable. It's also a lot of effort though :). I think I'll defer it for now and work on making generator expressions work for include directories and compile definitions and looking into creating INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_COMPILE_DEFINTIONS. I think most of that is realistic for 2.8.10. I'll try to find the bugs for that stuff in the backlog tomorrow and assign them to me and put them on the roadmap. 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> (... APPEND COMPILE_DEFINTIONS "$<$<CONFIG:Debug>:LOCATION=$<TARGET_PROPERTY:TYPE>>") This would mean I can avoid the explosion of TARGET_PROPERTY_FOO as well as a separate TARGET_PROPERTY for literals in the RHS, which is also needed anyway. What do 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