One configure step ought to be all you need. The whole point of CMake is to generate faithful implementations of the abstract build model. However, disappointingly many projects require you to manually re-run CMake before any incremental build. This should never be the case and is covered by the one-configure build recipe above. Some particularly pathological projects require you to run CMake twice up front in order to get a correct build. To keep this article focused, strategies for wrangling bad CMake (and non-CMake) dependencies will be covered in Part 3. Unfortunately, many CMake packages are not well-behaved. If you use only well-behaved CMake packages with find_package, this will largely take care of itself. The path of least resistance (using presets) both makes your CMakeLists.txt easy to maintain for you and easy to consume for all your users. Package maintainers, consumers of your library (if applicable), and power users looking to be on the cutting edge will all want to build your package with a slightly different set of flags, compilers, versions, and operating systems. Set default cmake generator Patch#On the other hand, incorrect CMake code inflicts an error with no recourse but to patch your build.ĭon't forget that other people besides your core development team will use your build. If a preset doesn't work for an end-user, they can override it piecemeal at the command line. # My eyes! The goggles do nothing! option( MyProj_ENABLE_WARNINGS "Compile MyProj with warnings used by upstream" OFF ) if ( MyProj_ENABLE_WARNINGS ) # keep line width low set( is_clang "$" ) set( is_gcc "$" ) set( ver "$" ) target_compile_options( target PRIVATE "$>:-Wsuggest-override>" "$>:-Wsuggest-override>" ) endif () The meaning of -Wall changes across compiler versions, so while this code might work for you today, it is at high risk of bit-rotting: The most common example is adding -Werror unconditionally. Such projects might needlessly fail on a different compiler or even a different version of the same compiler used by the author. Often, they provide no way to disable them. Unfortunately, many CMake builds assume too much about the environment or toolchain and inject optional, compiler-specific flags into their builds. Obviously, if you're building a Linux-only tool that depends on GNU extensions, then you will need GCC or Clang. $ cmake -install build -config Release -prefix /path/to/whereverįurthermore, if the code is standards-compliant and platform-independent, this sequence should work with any compiler on any operating system. $ cmake -install build -prefix /path/to/wherever Set default cmake generator generator#I'm going to make a bold claim, here: it should be possible to build any CMake project using any generator with the following sequence of commands, assuming all its dependencies are installed to system locations: I would encourage you to begin a friendly dialogue with the maintainers of non-conforming projects to see if they can be fixed (and, in the spirit of open source, try opening a PR!). Not every CMake project you encounter will meet these criteria. Today, I'd like to talk about what you should expect from a CMake build, and some common pitfalls that violate these expectations. I have added a list of these resources to the end of Part 1. Second, while I complained about the ocean of bad CMake resources, I forgot to recognize the handful of good resources that have taught me well. but all with an eye towards understanding why. Still, there will be some space dedicated to exploring specific effective practices, and pointing out common mistakes, superseded features, etc. I want readers to see the big picture and to develop a taste for quality build code. Set default cmake generator how to#My hope with this project is to show you how to reason about CMake so that it feels intuitive. Set default cmake generator series#Before we get started, I thought I would take this opportunity to clarify a couple of points about this series.įirst, this series is not a tutorial, at least not in the traditional sense. Welcome back to Part 2 of this series! I was very happy to see the warm reception Part 1 got over on /r/cpp. The views and opinions expressed in this website are those of Alex Reinking and do not necessarily reflect the views or positions of his employer.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |