You want to use an IDE, but maybe not all of the time.You need to support different OSs (maybe even just flavors of Unix).You want to use CI (continuous integration).You need to build a package on more than one computer.In short, here are the most likely questions in your mind if you are considering Modern CMake: Why do I need a good build system? Be sure to check the HSF CMake Training, as well! You can raise an issue or put in a merge request on GitLab. Not sure what I am missing.This book is meant to be a living document. It doesn’t appear to be smart enough to realize that the previous add_executable() and add_custom_command are supposed to create it. Cmake sees that it is not there (when Cmake is running, that is) and complains. My C++ static library project has a pre-build step runs a custom tool on a file named “a” to produce an output named “myfile.c” The “myfile.c” is supposed to be compiled into the static library.īut even after trying your approach, any attempt to reference that generated file “myfile.c” in the subsequent add_library() statement (for the static library) fails completely. This looks to be exactly what I want but unfortunately none of this works for the static library I’m trying to build. I stumbled across this trying to solve this very problem when porting a C++ project to Linux.
Alternatively, if the generator can be factored out into its own project, a more traditional superbuild approach using ExternalProject may be another alternative. Handling this sort of scenario requires more complicated techniques, with one effective solution being documented here. If the generator is built by the project, a chicken-and-egg situation results. A generator may produce a CMakeLists.txt file, for example, which means the generator has to exist at configure time before any build has been performed. One scenario not covered in the above is where one of the files being generated is a file read in by CMake as part of the configure stage. This lets CMake handle dependencies between the tool and the generation steps as well as being more suitable for parallel builds (in comparison, the configure stage is inherently non-parallel). Generating source files at build time is preferable where the generation is expensive or where it requires a tool that is itself built as part of the project. The main drawback to a configure-time copy is that if the configure stage is not fast, re-running CMake every time the input file changes can be annoying. If the file contents can be generated at configure time, this is often the simplest approach. The most effective way to generate content to be used as source files depends on a number of factors. The configure_file() command makes this trivial and even has the ability to transform the input such that $/generated.cpp The easiest scenario involves copying a file from somewhere into a known location during the configure stage and using it as a source or header file in the build stage. CMake provides a range of functionality which can be used to create files, but getting build dependencies correct is an area where many developers struggle or even simply give up. This is relatively easy with CMake, but things get more interesting when some of the source files need to be generated as part of the build. Using a set of source files to build libraries and executables is about the most basic thing a build system needs to do.