On 03/19/2013 04:02 PM, Alexander Neundorf wrote: > On Tuesday 19 March 2013, Stephen Kelly wrote: >> I don't mind renaming it, but it's a topic for the cmake list. > > So, I think the variable name CMAKE_BUILD_INTERFACE_INCLUDES is to general. > Since it is similar to the effect of CMAKE_INCLUDE_CURRENT_DIR, I suggest > renaming it e.g. to CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE.
The proposed name is much better. The old name was never in a final release so it is easy to rename now: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fc43477d >> applies to both the BUILD and INSTALL include interfaces. To limit it to >> one or the other, you have to specify it: >> >> target_include_directories(foo INTERFACE >> "$<BUILD_INTERFACE:/foo/interface/only>" >> ) > > Why was this generator expression approach chosen over simply adding suitable > keywords, as it is done for all other cmake commands ? > > target_include_directories(foo INTERFACE_BUILD ${CMAKE_CURRENT_SOURCE_DIR} > > ${CMAKE_CURRENT_SOURCE_DIR}/whatever/ > ${CMAKE_CURRENT_BINARY_DIR} > INTERFACE_INSTALL ${INCLUDE_INSTALL_DIR} ) The keywords won't interact well with PUBLIC/PRIVATE/INTERFACE keywords. Also the arguments are likely to be built up in lists: target_include_directories(foo PUBLIC ${foo_INCLUDE_DIRS} ${other_INCLUDE_DIRS} ) that may or may not contain multiple entries and multiple uses of each $<BUILD_INTERFACE:...> and $<INSTALL_INTERFACE:...> expression. The generator expressions bind tightly. -Brad _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
