Using project() for dependent CMake subdirectories

Question

I have several projects consisting of a few libraries, each living in its own subdirectory, knitted together by the topmost CMakeLists.txt file. I am in the habit of using project(<DIRNAME>) at the top of each CMakeLists.txt file and I try to structure the subprojects in such a way that they could be compiled separately from the top project. However, while this might make sense for standalone, core libraries, it cannot work for the libraries that depend on them because I need to do stuff like

target_link_libraries(gui core)

And core will nor be defined if I am trying to compile gui as a standalone project.

Is it wrong to use project() in this context, or am I missing something?

Answer 1

A Matter of Taste

This is in my opinion mainly a matter of taste. I don't think multiple project() commands itself are a problem, its more that projects I have seen using this approach tend to repeat itself in other parts and sometimes are running into problems with global cached variables.

Depending Libraries

The more relevant fact is, that the depending libraries will also add an include dependencies.

For standalone static library targets - not executable or shared library targets who really link the library - the simple target_link_libraries() command could be ignored with something like:

if (TARGET core)
    target_link_libraries(gui core)
endif()

But the header files include dependency remains.

Standalone Projects in CMake

For me a (sub-)project to be really standalone needs not only the project() command, but it should also have a export(TARGETS ...) command. Then you could e.g. use find_package() commands to resolve any open dependencies with something like:

if (NOT TARGET core)
    find_package(core REQUIRED)
endif()
target_link_libraries(gui core)

References

• Making cmake library accessible by other cmake packages automatically
• CMake share library with multiple executables