Brad King wrote: > On 05/19/2012 04:45 PM, Alexander Neundorf wrote: >> On Thursday 17 May 2012, David Cole wrote: >>> I don't think this conditional stuff in generator expressions is a good >>> idea at all. >> >> Me too ;-) > > The goal is to allow per-configuration/per-language/per-xyz values to > appear in places like the INCLUDE_DIRECTORIES property of a target. > Unlike COMPILE_DEFINITIONS the *order* of include directories matters. > Therefore we cannot have a separate INCLUDE_DIRECTORIES_<CONFIG> > property because there is no well-defined way to integrate its entries > with those of the main property. There was discussion of this back > when Stephen first brought up his patch for per-target include > directories. The solution is to have a single property only and put > the condition in the value. > > Since the configuration is not known until generate time any condition > based on the configuration must be evaluated at generate time. We need > to have generate-time evaluation of a condition stored in a value of a > property. This touches on a declarative specification. The closest we > have to this now is the "debug" and "optimized" keywords of tll().
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 I updated the wiki page too: http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements This problem is increasingly declarative. I'm not certain we can solve it in a declarative way though. Experience with the Qt QML system (which is declarative) shows that imperative style constructs can still overwrite declarative ones if you allow mixing. 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(): add_library(mylib ${PARMS}) # If we want to do complex things, we don't set the INCLUDE_PROPERTIES here. finalize(mylib) # Takes one target argument, and maybe a [PUBLIC|PRIVATE] # This scope contains variables which were set and cached when # project() was last invoked (so we can query the platform etc), # along with the target named itself. A limited subset of CMake commands # can be used here: # set() can be used, but only has a local effect. # if() and for() can be used. # set_property(TARGET) get_property(TARGET), get_target_property() and # set_target_properties() can be used. # target_link_libraries() and any other target_*() command can be used. set(additional_INCLUDE_DIRECTORIES "/foo/bar" "/bat/bang") if (CMAKE_BUILD_TYPE MATCHES Debug) list(APPEND additional_INCLUDE_DIRECTORIES "/foo/debugstuff") endif() if ("${CMAKE_C_COMPILER_ID} ${CMAKE_CXX_COMPILER_ID}" MATCHES SunPro) list(APPEND additional_INCLUDE_DIRECTORIES "/bar/some_sunpro_hack") endif () get_target_property(non_console mylib WIN32_EXECUTABLE) if (non_console) target_link_libraries(mylib ${Qt5WinMain_LIBRARIES}) endif() endfinalize() CMake would then look for cmFinalizeHelperCommand objects after Configure() and before Generate() and executate them. The content of them would also have to be stored on imported targets as a string if PUBLIC is specified. If a target has multiple cmFinalizeHelperCommands on it, they are executed in sequence (this might make finalize a bad name, but we can bikeshed that. post_configure()? pre_generate()?). Any comments on this? 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
