Some variables have different defaults based on the chosen configuration, e.g.Generator expressions can conditionally evaluate to different values based on the chosen configuration by using $.Some variables have special siblings which have a configuration in their name and are used only when the chosen configuration matches that name.įor example, CMAKE_CXX_FLAGS holds flags passed to the compiler for all configurations of all C++ artifacts, while CMAKE_CXX_FLAGS_DEBUG holds flags passed to the compiler (in addition to CMAKE_CXX_FLAGS) for only debug configurations of all C++ artifacts.The configuration has implications throughout the project. builds that are colloquially called "debug" and "release", but that distinction is independent of (albeit often correlated with) the configuration. The set of possible variations includes linking against different builds of dependencies.Īrtifacts may have "debug" and "release" builds, i.e. Recalling my earlier vocabulary, an artifact is a library or executable, and any variation in the construction of that artifact creates a uniquely identifiable build of the artifact, whether or not it changes the artifact's ABI. The configuration is a property of the build step. Now, with a single-configuration generator, we know what that configuration will be,īut it still doesn't make sense to think of the configuration as a property of the project. When using CMake to build, we build a configuration. What does it mean to talk about the configuration? Whenever I use the term configuration, I am referring to this choice, however it was made. Visual Studio 16 2019), the configuration is chosen at build time by the command-line option -config. The configuration is chosen at configure time by the CMAKE_BUILD_TYPE variable.įor multi-configuration generators (e.g. These two terms are often used interchangeably, but I will stick to configuration here.įor single-configuration generators (e.g. In CMake, a build type or configuration is a name. I have tried and will continue to try to keep the ideas general, but this post is colored very specifically by my experience with CMake. With no knowledge or concern of the underlying build system.ĬMake is the build system I have in the back of my mind as I write this series. Which lets users configure, build, test, and install projects in a cross-platform way by interacting with CMake only, I can already hear the shouts that it is not a build system, but a build system generator,īut that stopped being the case in my opinion when they added cmake -build in version 2.8, To the point of being a de facto standard. Up to this point, I have tried to avoid fixating on any particular build system,īecause I believe it is the one most widely used in the community, I gave an example of mixing debug builds of some dependencies with release builds of other dependencies in order to aid debugging of some components without paying the cost of slowing down all components.īut I've never actually seen it in practice,Īnd in my experience, it is difficult to achieve with CMake. dependents, to choose which build they use for each of the dependencies in their dependency graph. Recall that I want to make it easy for library users, i.e. In this post, I want to talk about the trouble with build types or configurations in CMake. In the second post, I explained the difference between local and global compiler flags. In the first post, I described my vision and introduced a vocabulary for this series. This is the third post in a series on C++ developer experience.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |