The CONFIGURE_DEPENDS flag may not work reliably on all generators, or if a new generator is added in the future that cannot support it, projects using it will be stuck. If no CMakeLists.txt file changes when a source is added or removed then the generated build system cannot know when to ask CMake to regenerate. Note We do not recommend using GLOB to collect a list of source files from your source tree. although, even on that page the CMake documentation states There is not a force on heaven or earth, or a chance in hell, that I would ever consider not using globbing. We have something between 500-1000 libs/exes in our cmake build, which in cmake terms ends up boiling down to maybe double or triple that number of targets because of fancy $reasonsĮach dll/exe gets it's own folder for source code, and it's own folder for public headers, and another one for "private" header files for things like test apps or unit tests to access.Īside from maybe 3-4 special case libraries where the actual build logic is complex enough to warrant rocking the boat, every single one of our hundreds and hundreds of libs/exes get their source files assigned by globbing.īut not just by globbing, but specifically globbing that happens in a helper function that no dev outside of my direct team, will ever look at or care about. Offering the heads-up is fine, but "We do not recommend." is unnecessary and leads people to view this as a CMake shortcoming.Īt $dayjob, we're converting a huge C++ codebase that uses an in-house build system to cmake. I wish the CMake developers would tweak the wording on their no-GLOB advice. We've been using this approach for years and it works great. To handle cases where a git checkout or merge adds, removes, or renames source files, we use a githook to touch a CMakeLists.txt file and trigger CMake to rerun. What we do instead is, when you yourself add, remove, or rename source files locally, just touch CMakeLists.txt to trigger CMake to rerun. So instead of banning GLOB, you could just require developers to change one character in a CMakeLists.txt file whenever they add, remove, or rename a source file! So ban GLOB, problem solved!īut really any modification to CMakeLists.txt accomplishes the same goal of triggering CMake to rerun. Banning GLOB thus forces developers to modify the CMakeLists.txt file whenever they add, remove, or rename a source file, which triggers a new build. ![]() What makes GLOB problematic is that the build system has no way to know when source files are added, removed, or renamed, so it doesn't know to rerun CMake when that happens. No source files in the source tree that aren't actually getting built distracting developers, who wonder "how can this old code still work.?" only to eventually realize that it's not being compiled.No more issues where a Windows developer adds a file to CMakeLists.txt with the wrong case, breaking the Linux build.Much shorter/easier to maintain CMakeLists.txt files.We use GLOB in our CMake files and it works great. Note: If the daemon is shutdown (system reboot) then the state is now unknown and all glob patterns will need to be re-evaluated. This solution offloads the overhead of continuous glob evaluation to a background process and will have the best of both worlds at the cost of increased complexity for the systems engineer. Monitor Filesystem Changes - A build system can spin up a background daemon to listen for file system changes that would impact the results of previous glob evaluations.This design has better incremental build performance, but can no longer guarantee an incremental build is equivalent to a full build. A build may detect deleted files, but will miss new files unless a user remembers to "force" a rebuild by touching the build definition. Cache globbed evaluation - The build will evaluate the glob patterns only when the build definition changes.This adds overhead to incremental builds and slows down the inner development loop for every invocation. Glob Source always evaluated - The build will re-evaluate ALL glob patterns for ALL incremental build to determine if the file system has changed since the last build.The big downside is large build definitions that increase maintenance costs. Any change to the input file set will invalidate the build definition and force a rebuild. Explicitly define all inputs - Allows for the build to know exactly what it needs to build and allows for very fast incremental build checks.There are four general ways to handle incremental builds: Globbing is amazing from a usability perspective but makes it very hard to have performant incremental builds with guaranteed correctness. This is a design decision where build systems must choose between incremental build speed and correctness over usability and CMake has to work toward the least common denominator.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |