If your minimum CMake version is 3.13 or later though, the third approach is inferior to the second and should be avoided in general. The article linked at the top of this answer goes into detail about why target_sources() can be advantageous. When using CMake 3.12 or earlier, one thing that this third approach allows which the second doesn't is you can use target_link_libraries() a bit more freely when using target_sources() to specify the source files in each subdirectory. Changes therefore become easier to merge and to understand in version control histories, etc. Both localise details about files in a directory to a CMakeLists.txt or other similarly named file in just that directory. The third option of one top level CMakeLists.txt file with each subdirectory providing a file brought in by include() is less common, but it has similarities to using one CMakeLists.txt file in each subdirectory. These separate scopes make it easier to apply things like compiler flags and other temporary values to just one section of a complex directory structure. Each subdirectory also gets its own directory property scope. in one part of the source tree but not have those changes visible in another part. This can be important if you want to set variables, etc. This structure offers you the ability to turn on/off whole sections of the build tree easily, but more importantly it gives each subdirectory its own variable scope. answer gives a good example of how this can be useful, so I won't repeat most of those details here. Once a project becomes non-trivial in size, most choose to add a CMakeLists.txt file in each subdirectory and use add_subdirectory() to bring them all together. This is especially true if you both add/remove a file, thereby both change the top level CMakeLists.txt file and have the possibility of a conflict. That may not seem like a big deal, but if multiple people are working on a project and you want to easily see what part of a project someone else's changes affect (e.g. It also has the disadvantage that a change for a file addition or removal isn't restricted to a particular directory. Once the project grows, keeping everything in the top level can become too much and make the resultant CMakeLists.txt file harder to follow. Having just one top level CMakeLists.txt file would only be recommended if there were very few files and subdirectories. Not the recommended approach in general though.Įach has its pros and cons. This method is less common, but can have advantages over the other two in some circumstances. The top level CMakeLists.txt file brings in the subdirectory files with include(). One CMakeLists.txt file at the top level, each subdirectory having its own file that lists its own source files and targets.This approach is very common and is usually the recommended one. One CMakeLists.txt file in each directory, each one brought in by its parent using add_subdirectory().You typically only see this for very simple projects. One CMakeLists.txt file at the top level which lists all the source files out in all the different subdirectories. I'll refer you to this article for an in-depth discussion of the two main approaches, but there's a few ways you could structure a project such as this.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |