CMake:VariablesListsStrings: Difference between revisions

From KitwarePublic
Jump to navigationJump to search
Line 13: Line 13:


==Strings vs. lists==
==Strings vs. lists==
In CMake all variables are of the type string. Nevertheless CMake can deal also with lists.
If a string contains semicolons, these semicolons can be interpreted as separators of string values.
set(MyString "Hello world")
This sets MyString to "Hello world", which is always only one string.
set(MyList Hello world)
This sets MyList to a list with the items "Hello" and "world". It will be stored as a string "Hello;world".


==Emulating maps==
==Emulating maps==

Revision as of 15:52, 2 January 2008

Scope of variables in CMake

In CMake variables don't have to be declared, they are created upon their first usage:

src/foo/CMakeLists.txt:

 set(SomeVariable "Hello world")

This creates (if it didn't exist yet) the variable SomeVariable. In CMake all variables in CMake are global. Global means that the variables exist in the file where they have been created, in all subdirectories connected using ADD_SUBDIRECTORY() or SUBDIRS(), and in all included files in any of these directories. They don't propagate up to the parent directories. Also if the value of a variable is changed in a subdirectory, the change doesn't propagate up to the variable in the parent directory.

Strings vs. lists

In CMake all variables are of the type string. Nevertheless CMake can deal also with lists. If a string contains semicolons, these semicolons can be interpreted as separators of string values.

set(MyString "Hello world")

This sets MyString to "Hello world", which is always only one string.

set(MyList Hello world)

This sets MyList to a list with the items "Hello" and "world". It will be stored as a string "Hello;world".

Emulating maps

Boolean values in CMake

Using CMake regexps

Escaping

The CMake cache