Brad King wrote: > On 08/14/2012 05:11 AM, Stephen Kelly wrote: >> Thanks, I'll see what I can figure out. >> >> I think at this point, I'm more interested in linking to a library based >> on the content of a target property (ie, linking QT_QTMAIN_LIBRARY based >> on whether WIN32_EXECUTABLE is set), so I may need to expand it along the >> lines you did for $<CONFIG:> first. > > I rebased the topic after the sweeping changes and merged it to next. > Please fetch "generator-expression-conditions" from the topic stage > and base your work on that instead.
Thanks, here are my findings so far, which relate to my extension of that branch at [email protected]:~steveire/cmake/steveires-cmake.git: 1) The result string of the $<CONFIG:...> expression does not allow lists. That means we can't do anything like this: include_directories("$<$<CONFIG:Release>:/foo;/bar/bat>") include_directories("$<$<CONFIG:Release>:${somedirs}>") # somedirs might contain a list I fixed that in my branch by modifying cmSystemTools::ExpandListArgument. 2) Because of the way generator expressions are parsed, the > character can't be part of the result string. This is an unlikely but possible character to appear in include directories for example. This seems to be because the generator expression can start and end anywhere in the input string to the Process method, instead of assuming that the start of the string is the start of the generator expression, and the end is the end of it. The latter probably makes more sense in the context of target property generator expressions. Eg, I'd prefer this to be illegal: include_directories("/tmp/$<$<CONFIG:Release>:foo/>bar") # Could include /tmp/bar or /tmp/foo/bar, but not very readable. Can this be changed? If it would break existing users of generator expressions, maybe we can enforce complete-string-generator-expressions if it is being used on a target (eg if (this->Target) inside Process() on my branch). 3) I can add something like $<TARGET_INTERFACE_INCLUDE_DIRS:tgt> in the future to expand to the interface include directories of a target (currently cmake has no such concept, but I'm thinking in the future). However, I don't think something like $<$<CONFIG:Release>:$<TARGET_INTERFACE_INCLUDE_DIRS:tgt>> would work, would it? The 'right hand side' of the expressions must be the final string? That was mostly just a thought experiment though. There wouldn't be any real need for TARGET_INTERFACE_INCLUDE_DIRS to be a generator expression instead of a static property on a target. If that is to be conditional on something like CONFIG:Release, that can just be in a generator expression in that TARGET_INTERFACE_INCLUDE_DIRS property anyway. I can't really think of a situation that that would be needed, but it is an interesting point which might be worth documenting. 4) I'm really not certain if I've implemented the patch for conditional link libraries in the right place. I tried a few different locations. I'm also not sure if there is logic at configure time which can't be implemented in terms of the generator expressions which are not evaluated by then. I tried using it with imported targets which had entries in their IMPORTED_LINK_INTERFACE_LIBRARIES, which seemed to work, so that's encouraging. 5) I think it's quite cool that I can add something like set(_WIN32_EXE "$<AND:$<TARGET_PROPERTY_STREQUAL:TYPE,EXECUTABLE>, $<TARGET_PROPERTY_BOOL:WIN32_EXECUTABLE>>") target_link_libraries(Qt5::Core LINK_INTERFACE_LIBRARIES "$<${_WIN32_EXE}:Qt5::WinMain>" ) and it will lie dormant and not have any effect on any shared libraries until it is finally linked to an executable :). Several features come together nicely there. 6) In my new implementation of cmTarget::GetIncludeDirectories, it is now necessary for that method to only be called at generate-time. As far as I can see, that is already true for that method, but for maintenance it is a bit difficult. Are there other examples of similar requirements of when an API can be meaningfully called? It seems to be something that could benefit from refactoring throughout cmake if so. 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
