For example, if many targets are being built up throughout a directory heirarchy, then the number and naming of variables can get out of hand. Variables used in this way are not a particularly robust way to record the source file list. One drawback is that the source files are built up in a variable and then that variable is passed to an add_library() or add_executable() call at the top level CMakeLists.txt file. The down sides of the above approach may not be immediately obvious. target_sources(): All The Advantages Without The Drawbacks Nevertheless, it is often used by developers new to CMake until they experience first hand the problems the technique introduces. While at first this may seem very attractive for its simplicity, this technique has a number of drawbacks and is actively discouraged by the CMake documentation. It also keeps the top level CMakeLists.txt file quite small and the CMakeLists.txt in each subdirectory also tends to be reasonably uncomplicated and focussed just on the things in that directory.Īs an alternative to explicitly building up a list of source files in a variable, some developers instead choose to let CMake find the source files and generate the contents of that variable automatically with the file(GLOB_RECURSE. This allows each subdirectory to define just the sources it provides and to delegate any further nested subdirectories with another include(). With the subdirectory files structured something like this: list(APPEND myApp_SOURCES # it doesn't have to be called CMakeLists.txt The top level CMakeLists.txt file then looks something like this: # The name of the included file could be anything, Then after all the subdirectories have been included, add_executable() or add_library() is called, but this time passing just the variable instead of an explicit list of files. The logical improvement many developers then make is to build up the list of source files in a variable as each subdirectory is pulled in via include(). It also results in having to repeat the directory structure, which reduces the benefit of structuring source files into directories in the first place. When the number of source files grows large and they get distributed over a number of subdirectories, possibly nested to multiple levels, this quickly becomes unwieldly. Eg: add_executable(myApp src1.cpp src2.cpp) Typically, developers first learn CMake in a very simple manner, defining a target by listing the source files directly in the add_executable() or add_library() command itself. Source files can be added to third party project targets without having to modify the third party project files.Source files gain the ability to become part of a target’s interface.Dependency information can be specified closer to where the actual dependencies exist in the directory hierarchy.It can lead to cleaner and more concise CMakeLists.txt project files.While the CMake documentation succintly describes what target_sources() does, it fails to highlight just how useful the new command is and why it promotes better CMake projects:
With CMake 3.1, a new command target_sources() was introduced which provides the missing piece among the various target_. In such projects, traditional approaches usually either list all source files at the top-most level or build up the list of source files in a variable and pass that to add_library(), add_executable(), etc. These files may be distributed across various subdirectories, which may themselves be nested multiple levels deep. In all but trivial CMake projects, it is common to find targets built from a large number of source files. Key updates are noted within the article.
Updated December 2018: Parts of this article have been reworked to account for improvements made with the CMake 3.13.0 release.
0 kommentar(er)
