2011/7/13 Andreas Pokorny <[email protected]> > Such an improvement would be very welcome.. but.. have you considered a > different user interface?
Yes, i have considered that. > E.g. take a look at static libraries, CMake already > does transitive dependency resolution (if i am not mistaken). It also > differs > between like "interface libraries" and "link libraries". Couldnt we > define something > like: > * header directories i need for building target A as a property of a > target > * header directories other targets need if they depend on target A > > then we would write in subdirectory foo: > > add_library(foo ....) > target_include_paths(foo include/foo ) > target_include_targets(foo bar) > target_include_targets would not even be required, target_link_libraries could handle that. Whenever a target is linked to a library, it also should use the appropriate include directories. then in a differerent subdirectory bar: > add_library(bar ...) > target_include_paths(bar include/bar src/mydirtystuff) > target_include_targets(bar foo) > # now since we do not want foo or any other target to access > src/mydirtystuff: > set_target_properties(bar PROPERTIES INCLUDE_INTERFACE_PATH include/bar ) > > The existing include_directories command could "call" > target_include_paths(..) internally > for all targets defined afterwards.. > This works iff there is a 1:1 relationship between targets and directories. Boost also has components that provide multiple libraries. And it also has (quite a lot) of header-only libraries, these are components that provide no library target at all. cheers, Daniel
_______________________________________________ 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://www.cmake.org/mailman/listinfo/cmake
