-1

Following is an extract of a typical cmake directory layout (I enclose directories in square brackets):

- [libxxx]
    - CMakeLists.txt
    - [include] 
        - CMakeLists.txt
        - [libxxx]
            - xxx.h
    - [src]
        - CMakeLists.txt
        - xxx.cpp
    - [tests]
        - CMakeLists.txt
        - mytest.cpp       

Personally I prefer many small projects instead of big ones and for that case the preferred build2 directory layout (build2 is the build system from Boris Kolpackov) seems more reasonable to me. The cmake analogy of the build2 layout would be:

- [libxxx]
    - CMakeLists.txt
    - [libxxx]
        - CMakeLists.txt
        - xxx.h
        - xxx.cpp
    - [tests]
        - CMakeLists.txt
        - mytest.cpp       

The reasoning for the canonical build2 layout is defended here. Furthermore, here the same layout is suggested as standard layout for any c++ project and in particular for projects switching to modules. The second link is to the end of the document where the acknowledgements are listed to show that this layout has actually been reviewed and is not just a personal opinion of some tool writer.

This layout merges src and include directories into a single projectname directory and if there are only few files in each project, then I see the advantage of reduced verbosity and flatter hierarchies.

Finally, when modules become mainstream, then the argument may lean even more towards merging include and src into a single directory.

Any reason not to follow the build2 layout recommendation with cmake projects?

  • 1
    Users of your library want to access the header files. This means that the include directory with the headers needs to be installed somewhere. In CMakeLists.txt, I find it convenient to use install(DIRECTORY include/ DESTINATION include) for that. This does not work with your approach. Other than that, I dont see any problems. – pschill Jan 14 at 14:17
  • @pschill, I understand your answer as follows: I should have separate src(with private files) versus include(with public files) directories because CMake does not support filtering out private stuff when using CMake to install the public stuff sourced from a directory (like target_include_directories for e.g.) that contains both public and private files. – Patrick Fromberg Jan 14 at 18:21
  • @pschill, I will go with your recommendation except for header only libraries and projects using modules. – Patrick Fromberg Jan 14 at 19:59
  • Personally I prefer ... You can use whatever you want. Try it out. See how it works out in the end. If or when you discover problems, we'll be happy to help. – JBRWilkinson Jan 15 at 14:10
  • @JBRWilkinson, unfortunately I have to find a compromise between what I want, what other developers want and sometimes even what tools like IDE's expect. I think a standard layout is very helpful and preferably that should be the same one for any build system or build system generator. – Patrick Fromberg Jan 15 at 18:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.