(In Stephen's analogy they might be member variables of a singleton). Global properties are also scoped to a single "global object". In summary, properties are primarily useful for their being "scoped" to something like a target. Its possible to have a ( 'global') variable and (global) property with the same name exist simultaneously (but the usefulness of such is not obvious). However, in addition to target properties, which are scoped to targets there are various other kinds which can instead be scoped to eg source, install, directory, global etc. I think Stephen Newell's answer captures the main motivation for properties (and the c++ analogy of member variables vs non-member variables is very helpful). The modern way is to set CXX_STANDARD prop instead. In "modern" CMake we are encouraged to think in terms of targets and the properties they have, instead of setting values to a disorganized bunch of variables, but properties weren't there initially it seems so some aspects can still be configured using variables.įor example, CMAKE_CXX_FLAGS var can be set to "-std=c++11" and will then affect the generation directly. So in general, values would flow throug cmake like this:Ĭommand line/option > variable > some processing > property >įor example, CXX_STANDARD prop can be set via set_property(), but will also initialize from the CMAKE_CXX_STANDARD var if it was given a value.
#Cmake vs make file difference generator#
In turn, the point of the configuration stage is to evaluate and note down all the facts that the generator might want to know when it is making its decisions. Remember that the point of running CMake is to have the selected generator output a set of makefiles (or IDE project files). Properties are predefined slots that together describe all aspects of the environment, the state and the project being configured. They can also be assigned in the command line and exposed as GUI options, to accept inputs from outside of the script. Variables are arbitrarily named memory cells you use during calculations and to pass values around.
After some reading and consulting, I believe the roles CMake intends for variables and properties are indeed different, and in fact more or less straightforward. I felt not entirely satisfied by the other answers, so I had to go and find my own. This means if you import Foo::bar (probably through something like find_package(Foo)), your project already knows that things linking against Foo::bar need to use C++14 ( INTERFACE_COMPILE_FEATURES), it needs to add something to the include path ( INTERFACE_INCLUDE_DIRECTORIES), and there are some source files it cares about (my headers, INTERFACE_SOURCES). If CMakeLists.txt was written in C++, that might look something like this: const char * src_files = /include/foo/bar.hpp" A very short and simple way to think about it is that properties are variables scoped to a target.
0 kommentar(er)
