i.e despite the existence of target_compile_options, if you need to add compiler options only to a C++ compile, you'll still have to use CMAKE_CXX_FLAGS. A surprising amount of CMake configuration is still done only through what seem to be 'global' variables - despite the existence of more modern forms. This actually can be put to use to simplify your CMakeLists.txt. This means add_subdirectory and function inherit the scope from the point where they're called, but modification will not be reflected in the parent scope. Here's the trick to understanding scopes in CMake: Unlike other languages, where name lookup would walk up the tree of scopes, each new scope is a copy by value of the parent scope at that point. When add_subdirectory is used to add a new directory to the CMake source tree andĮach scope when created maintains a link to its parent scope, and so you can think of all the scopes in a project as a tree.I am aware of two places where new scopes are created: The key to understanding variables in CMake in my mind is to understand where these variables get set. Variables are set in CMake using set: set(SOME_VARIABLE ) Variables and scopes in CMakeįirst, a quick note of caution: Variables exist in an entirely separate universe from properties, and so what I say about variables may well not apply to properties, which I am much less well versed in. We'll see how much I end up talking about CMake, but I'll start with a quick discussion of variables and scopes in CMake. There's a pretty steep ramp from 'This is amazing, a trivial CMakeLists.txt builds my project' to 'How do I do this slightly odd thing?' Once you start wandering into the woods, because your project has peculiar needs or requirements, things can get hairy pretty quickly. so long as you stay on the well trodden road.

I've been doing a lot of work on CMake for Eclipse OMRĬMake is a really ambitious project that accomplishes so much with such simplicity it's like magic.

Cmake set list