Hi, As discussed on the cmake user mailing list, I'm interesting in implementing the feature of target specific and configuration specific include directories.
http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/39090/focus=39114 I've pushed the target-include-directories branch to stage, which implements the feature. I started out as prototyping, but I ended up implementing API that I think makes sense. I have not merged it into next yet as it is not certain if it should be in the next release. I'd prefer it to be though if we can sort out the issues with what should be the target feature set. David mentioned one issue is whether the include directories of a target property should overwrite those of the directory property (added with the command include_directories). Like others on the other thread, I would expect the final list of includes to be determined by addition. For example: project(foo) include_directories(${bar_INCLUDES}) add_library(foo_lib ...) target_include_directories(foo CONFIG_TYPE DEBUG debug_helper.h) The target_include_directories command there shouldn't overwrite the ${bar_INCLUDES}. I can't think of any case where that would be wanted. The implementation in my branch so far makes the following possible: ** Both ${bar_INCLUDES} and ${spam_INCLUDES} are used when building foo. Only ${bar_INCLUDES} are available when building ham. include_directories(${bar_INCLUDES}) add_library(foo ...) target_include_directories(foo ${spam_INCLUDES}) add_library(ham ...) ---------------- ** ${spam_INCLUDES} appear before ${bar_INCLUDES} when building foo. include_directories(${bar_INCLUDES}) add_library(foo ...) target_include_directories(foo BEFORE ${spam_INCLUDES}) ---------------- ** Includes appear in the order spam > bar > yam when building foo. include_directories(${bar_INCLUDES}) add_library(foo ...) target_include_directories(foo BEFORE ${spam_INCLUDES}) target_include_directories(foo ${yam_INCLUDES}) ---------------- ** Includes appear in the order spam > par > bar > yam when building foo. include_directories(${bar_INCLUDES}) include_directories(BEFORE ${par_INCLUDES}) add_library(foo ...) target_include_directories(foo BEFORE ${spam_INCLUDES}) target_include_directories(foo ${yam_INCLUDES}) ---------------- ** ${yam_INCLUDES} are used when building foo in all configurations. ${spam_INCLUDES} are used only when CMAKE_BUILD_TYPE == Debug. add_library(foo ...) target_include_directories(foo CONFIG_TYPE DEBUG ${spam_INCLUDES}) target_include_directories(foo ${yam_INCLUDES}) ---------------- ** ${yam_INCLUDES} are used when building foo in all configurations. ${spam_INCLUDES} are used only when CMAKE_BUILD_TYPE == Debug, and they appear before the ${yam_INCLUDES} (and the directory level includes) add_library(foo ...) target_include_directories(foo BEFORE CONFIG_TYPE DEBUG ${spam_INCLUDES}) target_include_directories(foo ${yam_INCLUDES}) ---------------- The only thing potentially missing is a way to insert includes BEFORE others in the target include directories, but after the directory level includes. I can't think of any reason to want that and not simply be able to move the invokations of target_include_directories around. ie, target_include_directories(foo ${spam_INCLUDES}) target_include_directories(foo ${yam_INCLUDES}) instead of target_include_directories(foo ${yam_INCLUDES}) target_include_directories(foo ${spam_INCLUDES}) I imagine that in every case, the person writing those lines 'owns' foo, so they can control the positions of those lines. The bugs David listed in the other thread are: - http://public.kitware.com/Bug/view.php?id=1968 * Partially solved by this branch. Bug also requests source level includes. - http://public.kitware.com/Bug/view.php?id=6269 * Partially solved by this branch. Bug also requests config level link_directories and link libraries - http://public.kitware.com/Bug/view.php?id=6493 * Not affected by this branch as far as I see. - http://public.kitware.com/Bug/view.php?id=8189 * Not affected by this branch as far as I see. Bug requests source-level include directories. Issues: * I have only tried to implement this with the makefile generator and have so far only tested it with "Unix Makefiles". One of the bugs says XCode can't do source-level includes. Can it do target-level includes? Would I have to implement this for all generators before it would be considered for acceptance? * There's scope for refactoring the new code in my branch as well as potentially refactoring with the cmIncludeDirectoriesCommand. * There's scope for optimization. * I haven't written any tests yet. So before I merge this into next, I'm wondering if this feature can be considered for inclusion in 2.8.7? 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