在中型项目中CMake的最佳方法是什么？

Question

In my company, we're developing a middle sized project which we plan to use CMake as the build platform generator. In this scenario, me and my colleagues were discussing about which way the CMake should be used. Our discussions came to a turn which we must decide the methods to use. Our directory structure is similar to this:

<"our project"> \
   modules \
      module_1 \
         tests \
            test_example.cpp
         mock
            some_mock_class.hpp
         some_class.hpp
         some_class.cpp
         ...
      module_2 \
         ...
      module_3 \
         ...
   utility \
      ...

1- First thing is first, my colleague thinks that folders like "src" and "includes" are reminder of C programming and has no place in a modern C++ program, so we don't need them. So we removed them from the structure, but being a Linux guy; I'm not sure if this is a good idea. Should we set a "include" directory for headers, so CMake can install them appropriately to the include dirs of the install target; or can CMake handle them appropriately?

2- Should we make a CMakeLists.txt to the root of the project which includes and defines all the targets, or should we make a CMakeLists.txt per module, and then use "add_subdirectory" directives to include them? My colleague thinks on CMakeLists.txt is the best, because this way the module implementors don't need to think about CMake at all, and one or two admins of deployment can maintain the file; but I think every module implementor is more aware of which libraries they use, and how to compile their modules - which he disagrees. What do you suggest in this case?

If you did use CMake for such a middle-sized project before (or know of a case) can you please recommend us what they did and, if possible, why?

Sincerely

Answer 1

The topic is huge, but in short my personal recommendation. For a middle project I assime a component model should be already applied. Then reasonable then is, to have component directories with their onwn CMakeLists.txt which are referenced by the top-level CMakeLists.txt via add_subdirectory(). Each component - a separate library (I like static ones).

For the component folders I find reasonable to hide all internal stuff (aka implementation and private headers, ...) under a private sub-directory to do not be exposed to the outside. Then, in the top component directory you have only headers which are to be used by the others. In the private directory you can mix sources and headers - this is only a matter of the taste for mid projects. And the private directory can also be decomposed if the component is large. But then you need to decide either to add all artifacts to the single CMakeLists.txt of the component, or to have sub-libraries. But in that case the users should link to them individually instead to link to the component's library only.

In the best case, the folder structure should follow the dependencies structure and form a tree-view build system, where the components have as less knowlege about internals of the other components as possible. In that case you will have a good configurability and flexibility in case of possible refactorings. In the other words, the design of the build system seems to me similar to the class design in C++ - same principles.

The real (target) build directory where you run cmake can be located anywhere, normally outside of the source directory. A good place for it could be a RAM disc if you enough memory. Then for the clean build you need just to remove it, that's it. But the source and the build itself have no dependency from its location.

Ah yes, one more hint. My recommendation would be to include headers by the path starting from the component directory like #include "SomeHeader.hpp" which is located as ComponentX/SomeHeader.hpp. Then the CMakelists.txt is used to do the ComponentX directory known to your component. This means, the paths to the headers are not hardcoded in the source files. This brings some limitation like unique file names, but makes changes to the components location much easier.

Hope this anyhow helps.