Properties on Source Files
ABSTRACT
COMPILE_DEFINITIONS
COMPILE_DEFINITIONS_<CONFIG>
COMPILE_FLAGS
EXTERNAL_OBJECT
Fortran_FORMAT
GENERATED
HEADER_FILE_ONLY
KEEP_EXTENSION
LABELS
LANGUAGE
LOCATION
MACOSX_PACKAGE_LOCATION
OBJECT_DEPENDS
OBJECT_OUTPUTS
SYMBOLIC
WRAP_EXCLUDE

ABSTRACT
Is this source file an abstract class.
A property on a source file that indicates if the source file represents a class that is abstract. This only makes sense for languages that have a notion of an abstract class and it is only used by some tools that wrap classes into other languages.

COMPILE_DEFINITIONS
Preprocessor definitions for compiling a source file.
The COMPILE_DEFINITIONS property may be set to a semicolon-separated list of preprocessor definitions using the syntax VAR or VAR=value. Function-style definitions are not supported. CMake will automatically escape the value correctly for the native build system (note that CMake language syntax may require escapes to specify some values). This property may be set on a per-configuration basis using the name COMPILE_DEFINITIONS_<CONFIG> where <CONFIG> is an upper-case name (ex. "COMPILE_DEFINITIONS_DEBUG").
CMake will automatically drop some definitions that are not supported by the native build tool. The VS6 IDE does not support definition values with spaces (but NMake does). Xcode does not support per-configuration definitions on source files.
Disclaimer: Most native build tools have poor support for escaping certain values. CMake has work-arounds for many cases but some values may just not be possible to pass correctly. If a value does not seem to be escaped correctly, do not attempt to work-around the problem by adding escape sequences to the value. Your work-around may break in a future version of CMake that has improved escape support. Instead consider defining the macro in a (configured) header file. Then report the limitation. Known limitations include:

  #          - broken almost everywhere
  ;          - broken in VS IDE and Borland Makefiles
  ,          - broken in VS IDE
  %          - broken in some cases in NMake
  & |        - broken in some cases on MinGW
  ^ < > \"   - broken in most Make tools on Windows

CMake does not reject these values outright because they do work in some cases. Use with caution.

COMPILE_DEFINITIONS_<CONFIG>
Per-configuration preprocessor definitions on a source file.
This is the configuration-specific version of COMPILE_DEFINITIONS. Note that Xcode does not support per-configuration source file flags so this property will be ignored by the Xcode generator.

COMPILE_FLAGS
Additional flags to be added when compiling this source file.
These flags will be added to the list of compile flags when this source file builds. Use COMPILE_DEFINITIONS to pass additional preprocessor definitions.

EXTERNAL_OBJECT
If set to true then this is an object file.
If this property is set to true then the source file is really an object file and should not be compiled. It will still be linked into the target though.

Fortran_FORMAT
Set to FIXED or FREE to indicate the Fortran source layout.
This property tells CMake whether a given Fortran source file uses fixed-format or free-format. CMake will pass the corresponding format flag to the compiler. Consider using the target-wide Fortran_FORMAT property if all source files in a target share the same format.

GENERATED
Is this source file generated as part of the build process.
If a source file is generated by the build process CMake will handle it differently in terms of dependency checking etc. Otherwise having a non-existent source file could create problems.

HEADER_FILE_ONLY
Is this source file only a header file.
A property on a source file that indicates if the source file is a header file with no associated implementation. This is set automatically based on the file extension and is used by CMake to determine is certain dependency information should be computed.

KEEP_EXTENSION
Make the output file have the same extension as the source file.
If this property is set then the file extension of the output file will be the same as that of the source file. Normally the output file extension is computed based on the language of the source file, for example .cxx will go to a .o extension.

LABELS
Specify a list of text labels associated with a source file.
This property has meaning only when the source file is listed in a target whose LABELS property is also set. No other semantics are currently specified.

LANGUAGE
What programming language is the file.
A property that can be set to indicate what programming language the source file is. If it is not set the language is determined based on the file extension. Typical values are CXX C etc. Setting this property for a file means this file will be compiled. Do not set this for header or files that should not be compiled.

LOCATION
The full path to a source file.
A read only property on a SOURCE FILE that contains the full path to the source file.

MACOSX_PACKAGE_LOCATION
Place a source file inside a Mac OS X bundle, CFBundle, or framework.
Executable targets with the MACOSX_BUNDLE property set are built as Mac OS X application bundles on Apple platforms. Shared library targets with the FRAMEWORK property set are built as Mac OS X frameworks on Apple platforms. Module library targets with the BUNDLE property set are built as Mac OS X CFBundle bundles on Apple platforms. Source files listed in the target with this property set will be copied to a directory inside the bundle or framework content folder specified by the property value. For bundles the content folder is "<name>.app/Contents". For frameworks the content folder is "<name>.framework/Versions/<version>". For cfbundles the content folder is "<name>.bundle/Contents" (unless the extension is changed). See the PUBLIC_HEADER, PRIVATE_HEADER, and RESOURCE target properties for specifying files meant for Headers, PrivateHeaders, or Resources directories.

OBJECT_DEPENDS
Additional files on which a compiled object file depends.
Specifies a semicolon-separated list of full-paths to files on which any object files compiled from this source file depend. An object file will be recompiled if any of the named files is newer than it.
This property need not be used to specify the dependency of a source file on a generated header file that it includes. Although the property was originally introduced for this purpose, it is no longer necessary. If the generated header file is created by a custom command in the same target as the source file, the automatic dependency scanning process will recognize the dependency. If the generated header file is created by another target, an inter-target dependency should be created with the add_dependencies command (if one does not already exist due to linking relationships).

OBJECT_OUTPUTS
Additional outputs for a Makefile rule.
Additional outputs created by compilation of this source file. If any of these outputs is missing the object will be recompiled. This is supported only on Makefile generators and will be ignored on other generators.

SYMBOLIC
Is this just a name for a rule.
If SYMBOLIC (boolean) is set to true the build system will be informed that the source file is not actually created on disk but instead used as a symbolic name for a build rule.

WRAP_EXCLUDE
Exclude this source file from any code wrapping techniques.
Some packages can wrap source files into alternate languages to provide additional functionality. For example, C++ code can be wrapped into Java or Python etc using SWIG etc. If WRAP_EXCLUDE is set to true (1 etc) that indicates then this source file should not be wrapped.

Properties on Cache Entries
ADVANCED
HELPSTRING
MODIFIED
STRINGS
TYPE
VALUE

ADVANCED
True if entry should be hidden by default in GUIs.
This is a boolean value indicating whether the entry is considered interesting only for advanced configuration. The mark_as_advanced() command modifies this property.

HELPSTRING
Help associated with entry in GUIs.
This string summarizes the purpose of an entry to help users set it through a CMake GUI.

MODIFIED
Internal management property. Do not set or get.
This is an internal cache entry property managed by CMake to track interactive user modification of entries. Ignore it.

STRINGS
Enumerate possible STRING entry values for GUI selection.
For cache entries with type STRING, this enumerates a set of values. CMake GUIs may use this to provide a selection widget instead of a generic string entry field. This is for convenience only. CMake does not enforce that the value matches one of those listed.

TYPE
Widget type for entry in GUIs.
Cache entry values are always strings, but CMake GUIs present widgets to help users set values. The GUIs use this property as a hint to determine the widget type. Valid TYPE values are:

  BOOL          = Boolean ON/OFF value.
  PATH          = Path to a directory.
  FILEPATH      = Path to a file.
  STRING        = Generic string value.
  INTERNAL      = Do not present in GUI at all.
  STATIC        = Value managed by CMake, do not change.
  UNINITIALIZED = Type not yet specified.

Generally the TYPE of a cache entry should be set by the command which creates it (set, option, find_library, etc.).

VALUE
Value of a cache entry.
This property maps to the actual value of a cache entry. Setting this property always sets the value without checking, so use with care.

Compatibility Commands
build_name
exec_program
export_library_dependencies
install_files
install_programs
install_targets
link_libraries
make_directory
output_required_files
remove
subdir_depends
subdirs
use_mangled_mesa
utility_source
variable_requires
write_file

  CMake Compatibility Listfile Commands - Obsolete commands supported by CMake for compatibility.

This is the documentation for now obsolete listfile commands from previous CMake versions, which are still supported for compatibility reasons. You should instead use the newer, faster and shinier new commands. ;-)

build_name
Deprecated. Use ${CMAKE_SYSTEM} and ${CMAKE_CXX_COMPILER} instead.

  build_name(variable)

Sets the specified variable to a string representing the platform and compiler settings. These values are now available through the CMAKE_SYSTEM and CMAKE_CXX_COMPILER variables.

exec_program
Deprecated. Use the execute_process() command instead.
Run an executable program during the processing of the CMakeList.txt file.

  exec_program(Executable [directory in which to run]
               [ARGS <arguments to executable>]
               [OUTPUT_VARIABLE <var>]
               [RETURN_VALUE <var>])

The executable is run in the optionally specified directory. The executable can include arguments if it is double quoted, but it is better to use the optional ARGS argument to specify arguments to the program. This is because cmake will then be able to escape spaces in the executable path. An optional argument OUTPUT_VARIABLE specifies a variable in which to store the output. To capture the return value of the execution, provide a RETURN_VALUE. If OUTPUT_VARIABLE is specified, then no output will go to the stdout/stderr of the console running cmake.

export_library_dependencies
Deprecated. Use INSTALL(EXPORT) or EXPORT command.
This command generates an old-style library dependencies file. Projects requiring CMake 2.6 or later should not use the command. Use instead the install(EXPORT) command to help export targets from an installation tree and the export() command to export targets from a build tree.
The old-style library dependencies file does not take into account per-configuration names of libraries or the LINK_INTERFACE_LIBRARIES target property.

  export_library_dependencies(<file> [APPEND])

Create a file named <file> that can be included into a CMake listfile with the INCLUDE command. The file will contain a number of SET commands that will set all the variables needed for library dependency information. This should be the last command in the top level CMakeLists.txt file of the project. If the APPEND option is specified, the SET commands will be appended to the given file instead of replacing it.

install_files
Deprecated. Use the install(FILES ) command instead.
This command has been superceded by the install command. It is provided for compatibility with older CMake code. The FILES form is directly replaced by the FILES form of the install command. The regexp form can be expressed more clearly using the GLOB form of the file command.

  install_files(<dir> extension file file ...)

Create rules to install the listed files with the given extension into the given directory. Only files existing in the current source tree or its corresponding location in the binary tree may be listed. If a file specified already has an extension, that extension will be removed first. This is useful for providing lists of source files such as foo.cxx when you want the corresponding foo.h to be installed. A typical extension is '.h'.

  install_files(<dir> regexp)

Any files in the current source directory that match the regular expression will be installed.

  install_files(<dir> FILES file file ...)

Any files listed after the FILES keyword will be installed explicitly from the names given. Full paths are allowed in this form.
The directory <dir> is relative to the installation prefix, which is stored in the variable CMAKE_INSTALL_PREFIX.

install_programs
Deprecated. Use the install(PROGRAMS ) command instead.
This command has been superceded by the install command. It is provided for compatibility with older CMake code. The FILES form is directly replaced by the PROGRAMS form of the INSTALL command. The regexp form can be expressed more clearly using the GLOB form of the FILE command.

  install_programs(<dir> file1 file2 [file3 ...])
  install_programs(<dir> FILES file1 [file2 ...])

Create rules to install the listed programs into the given directory. Use the FILES argument to guarantee that the file list version of the command will be used even when there is only one argument.

  install_programs(<dir> regexp)

In the second form any program in the current source directory that matches the regular expression will be installed.
This command is intended to install programs that are not built by cmake, such as shell scripts. See the TARGETS form of the INSTALL command to create installation rules for targets built by cmake.
The directory <dir> is relative to the installation prefix, which is stored in the variable CMAKE_INSTALL_PREFIX.

install_targets
Deprecated. Use the install(TARGETS ) command instead.
This command has been superceded by the install command. It is provided for compatibility with older CMake code.

  install_targets(<dir> [RUNTIME_DIRECTORY dir] target target)

Create rules to install the listed targets into the given directory. The directory <dir> is relative to the installation prefix, which is stored in the variable CMAKE_INSTALL_PREFIX. If RUNTIME_DIRECTORY is specified, then on systems with special runtime files (Windows DLL), the files will be copied to that directory.

link_libraries
Deprecated. Use the target_link_libraries() command instead.
Link libraries to all targets added later.

  link_libraries(library1 <debug | optimized> library2 ...)

Specify a list of libraries to be linked into any following targets (typically added with the add_executable or add_library calls). This command is passed down to all subdirectories. The debug and optimized strings may be used to indicate that the next library listed is to be used only for that specific type of build.

make_directory
Deprecated. Use the file(MAKE_DIRECTORY ) command instead.

  make_directory(directory)

Creates the specified directory. Full paths should be given. Any parent directories that do not exist will also be created. Use with care.

output_required_files
Deprecated. Approximate C preprocessor dependency scanning.
This command exists only because ancient CMake versions provided it. CMake handles preprocessor dependency scanning automatically using a more advanced scanner.

  output_required_files(srcfile outputfile)

Outputs a list of all the source files that are required by the specified srcfile. This list is written into outputfile. This is similar to writing out the dependencies for srcfile except that it jumps from .h files into .cxx, .c and .cpp files if possible.

remove
Deprecated. Use the list(REMOVE_ITEM ) command instead.

  remove(VAR VALUE VALUE ...)

Removes VALUE from the variable VAR. This is typically used to remove entries from a vector (e.g. semicolon separated list). VALUE is expanded.

subdir_depends
Deprecated. Does nothing.

  subdir_depends(subdir dep1 dep2 ...)

Does not do anything. This command used to help projects order parallel builds correctly. This functionality is now automatic.

subdirs
Deprecated. Use the add_subdirectory() command instead.
Add a list of subdirectories to the build.

  subdirs(dir1 dir2 ...[EXCLUDE_FROM_ALL exclude_dir1 exclude_dir2 ...]
          [PREORDER] )

Add a list of subdirectories to the build. The add_subdirectory command should be used instead of subdirs although subdirs will still work. This will cause any CMakeLists.txt files in the sub directories to be processed by CMake. Any directories after the PREORDER flag are traversed first by makefile builds, the PREORDER flag has no effect on IDE projects. Any directories after the EXCLUDE_FROM_ALL marker will not be included in the top level makefile or project file. This is useful for having CMake create makefiles or projects for a set of examples in a project. You would want CMake to generate makefiles or project files for all the examples at the same time, but you would not want them to show up in the top level project or be built each time make is run from the top.

use_mangled_mesa
Copy mesa headers for use in combination with system GL.

  use_mangled_mesa(PATH_TO_MESA OUTPUT_DIRECTORY)

The path to mesa includes, should contain gl_mangle.h. The mesa headers are copied to the specified output directory. This allows mangled mesa headers to override other GL headers by being added to the include directory path earlier.

utility_source
Specify the source tree of a third-party utility.

  utility_source(cache_entry executable_name
                 path_to_source [file1 file2 ...])

When a third-party utility's source is included in the distribution, this command specifies its location and name. The cache entry will not be set unless the path_to_source and all listed files exist. It is assumed that the source tree of the utility will have been built before it is needed.
When cross compiling CMake will print a warning if a utility_source() command is executed, because in many cases it is used to build an executable which is executed later on. This doesn't work when cross compiling, since the executable can run only on their target platform. So in this case the cache entry has to be adjusted manually so it points to an executable which is runnable on the build host.

variable_requires
Deprecated. Use the if() command instead.
Assert satisfaction of an option's required variables.

  variable_requires(TEST_VARIABLE RESULT_VARIABLE
                    REQUIRED_VARIABLE1
                    REQUIRED_VARIABLE2 ...)

The first argument (TEST_VARIABLE) is the name of the variable to be tested, if that variable is false nothing else is done. If TEST_VARIABLE is true, then the next argument (RESULT_VARIABLE) is a variable that is set to true if all the required variables are set. The rest of the arguments are variables that must be true or not set to NOTFOUND to avoid an error. If any are not true, an error is reported.

write_file
Deprecated. Use the file(WRITE ) command instead.

  write_file(filename "message to write"... [APPEND])

The first argument is the file name, the rest of the arguments are messages to write. If the argument APPEND is specified, then the message will be appended.
NOTE 1: file(WRITE ... and file(APPEND ... do exactly the same as this one but add some more functionality.
NOTE 2: When using write_file the produced file cannot be used as an input to CMake (CONFIGURE_FILE, source file ...) because it will lead to an infinite loop. Use configure_file if you want to generate input files to CMake.