CODEWITHSUNDEEP
cmake
Aleph
Aleph

Reputation: 1373

Which file organization for CMake? Should CMakeLists.txt include other files?

I use CMake to configure, build and install a C++ code. I have defined some user options. I have added an option to let CMake download external depedencies. Etc, etc.

For the moment, everything concerning CMake is written in a single file CMakeLists.txt. There is also a configuration file 'config.cmake' which allows users to define various parameters such as verbosity level, paths to libraries, flags for compilers, etc.

What is a good file organization for CMake? Should CMakeLists.txt file be divided into subfiles?

Thank you very much for your help!

Upvotes: 1

Views: 1092

Answers (1)

starseeker
starseeker

Reputation: 149

A good file organization depends on how large your CMake logic is, or how large you expect it to become. Generally speaking:

  1. Functionality that may get reused a lot you probably will want to organize into "per topic" .cmake files which contain macros, and include them in your other CMakeLists.txt files to load that functionality. You'll find lots of these already out there on the web (custom Find*.cmake files for locating particular system libraries are quite common, for example.) A common convention is to have a directory "CMake" in your toplevel source directory, although other configurations are possible.

  2. If you have a lot of different build targets with their own unique source files (multiple libraries in a single project, for example) it is good practice to separate those into subdirectories and have one CMakeLists.txt file per subdirectory, with the toplevel CMakeLists.txt file using add_subdirectory to "hook them in" to the main build.

A "typical" structure for a project could look like this:

project/
        CMakeLists.txt
        README
        CMake/
           FindSpecialtyLib1.cmake
           FindSpecialtyLib2.cmake
           CustomCMakeMacroA.cmake
              etc...
        include/
           CMakeLists.txt (for installing headers, etc. if needed.)
        src/
           CMakeLists.txt (top level switching logic per user settings, etc.)
           lib1/
              CMakeLists.txt
              src1.cxx
              src2.cxx
           lib2/
              CMakeLists.txt
              src1.cxx
              src2.c
              private_header.h

That's just a hypothetical example, of course - you'll want to shape your logic to your specific project. Since you mention a config.cmake file, it's probably worth mentioning that the majority of variable setting of that sort is usually done in the cmake-gui or from -D definitions at the CMake command line, in my experience. A config.cmake works as a way to group options, but most users are probably going to start with the gui when it comes to setting things. I also recommend checking the CMake email archives for specific questions - I've found it to be an extremely helpful resource.

Upvotes: 5

Related Questions