Cmake include subdirectories8/3/2023 When a project has the complex structure and includes one or more subdirectories (project root and subdirectories), you can create subdirectory CMakeList.txt files. The source_dir specifies the directory in which the source CMakeLists.txt and code files are located. It shows that your CMake structure is not setup according to the rule of thumb quoted above.Īdd a subdirectory to the build. What you should avoid is having to reference source files out of other subdirectories with something like. CMake will create a new variable scope with each add_subdirectory() call ( the big difference to using include() command).CMake will mirror your add_subdirectory() and CMakeLists.txt directory structure in its generated build environment.To achieve this your project structure may have to adapt, if "each source file from the subfolders creates a separate executable".Īnd the root CMakeLists.txt is your starting point and contains the project() command. The most commonly used rule is "One CMakeLists.txt per target". (I'm a cmake noob, trying to convert a relatively large project to use cmake) Looking at projects using cmake I see no consistency, so this doesn't help much. All the tutorials I could find for multi-directory project deal with the case when there's a standalone library in one folder, standalone application using that library in another folder and standalone tests using the same library in yet another directory. I would like know which is the "preferred" way in a "modern" cmake project. The third option seems like an easy way to quickly create a CMakeLists.txt file with a length of a spaghetti, so it possible I would prefer something else. I would also have to prefix the names of output files. If there's only one level of nesting (like for first two example subfolders) it is ok, but for some/deeply/nested/path/SomeFeature-unit-test this is not so nice. But then in each some-random-name.cmake in subfolders I have to use full path to source files, which is against my desire for each of them to be self contained. The second option seems to clearly suggest that there is only one cmake project here. The first option is the most convenient, but it suggests that each subfolder is actually a standalone project which could be compiled separately. ignore my idea for each subfolder to be self-contained and put all relevant build info in the top-level CMakeLists.txt, additional cmake files only as helpers (macros, functions.some-random-name.cmake in each subfolder + include() in top-level CmakeLists.txt.CMakeLists.txt file in each subfolder + add_subdirectory() in top-level CmakeLists.txt.For example I don't want to make an impression that you could run cmake only from some/deeply/nested/path/SomeFeature-unit-test to build only that. I would like to be able to only build everything or nothing. I would like to have each subfolder in the project to be a non-standalone module - that is each subfolder is (more-or-less) self-contained, but is NOT a standalone cmake project which can be compiled separately. │ └── C-API-ConditionVariable-unit-test-1.cppĮach source file from the subfolders creates a separate executable. │ ├── C-API-ConditionVariable-unit-test-0.cpp │ ├── C-API-ConditionVariable-compile-link-test.c Let's say I have a C++ unit-test project using cmake like this: $ tree
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |