[CMake] $<> expressions in include_directories command

Daniel Pfeifer purplekarrot at gmail.com
Wed Jul 13 03:49:07 EDT 2011


2011/7/13 Andreas Pokorny <andreas.pokorny at gmail.com>

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110713/d624364b/attachment.htm>


More information about the CMake mailing list