Imagine the following scenario: Project A is a shared library which has several dependencies (LibA, LibB, and LibC). Project B is an executable that has a dependency on proj
Alexander Shukaev's got a great start, but there are a number of things that could be done better:
target_include_directories. However, you probably don't even need to do that if you use the imported targets.Use the imported targets. Example for Boost:
find_package(Boost 1.56 REQUIRED COMPONENTS
date_time filesystem iostreams)
add_executable(foo foo.cc)
target_link_libraries(foo
PRIVATE
Boost::date_time
Boost::filesystem
Boost::iostreams
)
This takes care of the include directories, libraries, etc. If you used Boost in your headers in B, then instead of PRIVATE, use PUBLIC, and these dependencies would be transitively added to whatever depends on B.
Don't use file globing (unless you use 3.12). Until very recently, file globbing only works during configuration time, so if you add files and build, it cannot detect the changes until you explicitly regenerate the project. However if you list the files directly, and attempt to build, it should recognize the configuration is out of date and regenerate automatically in the build step.
There's good talk here (YouTube): C++Now 2017: Daniel Pfeifer “Effective CMake"
Which covers a package manager idea that allows your root level CMake to work with find_package OR subdirectory, though, I've been trying to adopt the ideology of this and am having big problems with using find_package for everything and having a directory structure like yours.