Provided by: cmake-data_2.8.12.2-0ubuntu3_all 
NAME
cmakepolicies - Reference of CMake policies.
DESCRIPTION
The "cmake" executable is the CMake command-line interface. It may be used to configure
projects in scripts. Project configuration settings may be specified on the command line
with the -D option. The -i option will cause cmake to interactively prompt for such
settings.
CMake is a cross-platform build system generator. Projects specify their build process
with platform-independent CMake listfiles included in each directory of a source tree with
the name CMakeLists.txt. Users build a project by using CMake to generate a build system
for a native tool on their platform.
POLICIES
CMP0000
A minimum required CMake version must be specified.
CMake requires that projects specify the version of CMake to which they have been
written. This policy has been put in place so users trying to build the project
may be told when they need to update their CMake. Specifying a version also helps
the project build with CMake versions newer than that specified. Use the
cmake_minimum_required command at the top of your main CMakeLists.txt file:
cmake_minimum_required(VERSION <major>.<minor>)
where "<major>.<minor>" is the version of CMake you want to support (such as
"2.6"). The command will ensure that at least the given version of CMake is
running and help newer versions be compatible with the project. See documentation
of cmake_minimum_required for details.
Note that the command invocation must appear in the CMakeLists.txt file itself; a
call in an included file is not sufficient. However, the cmake_policy command may
be called to set policy CMP0000 to OLD or NEW behavior explicitly. The OLD
behavior is to silently ignore the missing invocation. The NEW behavior is to
issue an error instead of a warning. An included file may set CMP0000 explicitly
to affect how this policy is enforced for the main CMakeLists.txt file.
This policy was introduced in CMake version 2.6.0.
CMP0001
CMAKE_BACKWARDS_COMPATIBILITY should no longer be used.
The OLD behavior is to check CMAKE_BACKWARDS_COMPATIBILITY and present it to the
user. The NEW behavior is to ignore CMAKE_BACKWARDS_COMPATIBILITY completely.
In CMake 2.4 and below the variable CMAKE_BACKWARDS_COMPATIBILITY was used to
request compatibility with earlier versions of CMake. In CMake 2.6 and above all
compatibility issues are handled by policies and the cmake_policy command.
However, CMake must still check CMAKE_BACKWARDS_COMPATIBILITY for projects written
for CMake 2.4 and below.
This policy was introduced in CMake version 2.6.0. CMake version 2.8.12.2 warns
when the policy is not set and uses OLD behavior. Use the cmake_policy command to
set it to OLD or NEW explicitly.
CMP0002
Logical target names must be globally unique.
Targets names created with add_executable, add_library, or add_custom_target are
logical build target names. Logical target names must be globally unique because:
- Unique names may be referenced unambiguously both in CMake
code and on make tool command lines.
- Logical names are used by Xcode and VS IDE generators
to produce meaningful project names for the targets.
The logical name of executable and library targets does not have to correspond to
the physical file names built. Consider using the OUTPUT_NAME target property to
create two targets with the same physical name while keeping logical names
distinct. Custom targets must simply have globally unique names (unless one uses
the global property ALLOW_DUPLICATE_CUSTOM_TARGETS with a Makefiles generator).
This policy was introduced in CMake version 2.6.0. CMake version 2.8.12.2 warns
when the policy is not set and uses OLD behavior. Use the cmake_policy command to
set it to OLD or NEW explicitly.
CMP0003
Libraries linked via full path no longer produce linker search paths.
This policy affects how libraries whose full paths are NOT known are found at link
time, but was created due to a change in how CMake deals with libraries whose full
paths are known. Consider the code
target_link_libraries(myexe /path/to/libA.so)
CMake 2.4 and below implemented linking to libraries whose full paths are known by
splitting them on the link line into separate components consisting of the linker
search path and the library name. The example code might have produced something
like
... -L/path/to -lA ...
in order to link to library A. An analysis was performed to order multiple link
directories such that the linker would find library A in the desired location, but
there are cases in which this does not work. CMake versions 2.6 and above use the
more reliable approach of passing the full path to libraries directly to the linker
in most cases. The example code now produces something like
... /path/to/libA.so ....
Unfortunately this change can break code like
target_link_libraries(myexe /path/to/libA.so B)
where "B" is meant to find "/path/to/libB.so". This code is wrong because the user
is asking the linker to find library B but has not provided a linker search path
(which may be added with the link_directories command). However, with the old
linking implementation the code would work accidentally because the linker search
path added for library A allowed library B to be found.
In order to support projects depending on linker search paths added by linking to
libraries with known full paths, the OLD behavior for this policy will add the
linker search paths even though they are not needed for their own libraries. When
this policy is set to OLD, CMake will produce a link line such as
... -L/path/to /path/to/libA.so -lB ...
which will allow library B to be found as it was previously. When this policy is
set to NEW, CMake will produce a link line such as
... /path/to/libA.so -lB ...
which more accurately matches what the project specified.
The setting for this policy used when generating the link line is that in effect
when the target is created by an add_executable or add_library command. For the
example described above, the code
cmake_policy(SET CMP0003 OLD) # or cmake_policy(VERSION 2.4)
add_executable(myexe myexe.c)
target_link_libraries(myexe /path/to/libA.so B)
will work and suppress the warning for this policy. It may also be updated to work
with the corrected linking approach:
cmake_policy(SET CMP0003 NEW) # or cmake_policy(VERSION 2.6)
link_directories(/path/to) # needed to find library B
add_executable(myexe myexe.c)
target_link_libraries(myexe /path/to/libA.so B)
Even better, library B may be specified with a full path:
add_executable(myexe myexe.c)
target_link_libraries(myexe /path/to/libA.so /path/to/libB.so)
When all items on the link line have known paths CMake does not check this policy
so it has no effect.
Note that the warning for this policy will be issued for at most one target. This
avoids flooding users with messages for every target when setting the policy once
will probably fix all targets.
This policy was introduced in CMake version 2.6.0. CMake version 2.8.12.2 warns
when the policy is not set and uses OLD behavior. Use the cmake_policy command to
set it to OLD or NEW explicitly.
CMP0004
Libraries linked may not have leading or trailing whitespace.
CMake versions 2.4 and below silently removed leading and trailing whitespace from
libraries linked with code like
target_link_libraries(myexe " A ")
This could lead to subtle errors in user projects.
The OLD behavior for this policy is to silently remove leading and trailing
whitespace. The NEW behavior for this policy is to diagnose the existence of such
whitespace as an error. The setting for this policy used when checking the library
names is that in effect when the target is created by an add_executable or
add_library command.
This policy was introduced in CMake version 2.6.0. CMake version 2.8.12.2 warns
when the policy is not set and uses OLD behavior. Use the cmake_policy command to
set it to OLD or NEW explicitly.
CMP0005
Preprocessor definition values are now escaped automatically.
This policy determines whether or not CMake should generate escaped preprocessor
definition values added via add_definitions. CMake versions 2.4 and below assumed
that only trivial values would be given for macros in add_definitions calls. It
did not attempt to escape non-trivial values such as string literals in generated
build rules. CMake versions 2.6 and above support escaping of most values, but
cannot assume the user has not added escapes already in an attempt to work around
limitations in earlier versions.
The OLD behavior for this policy is to place definition values given to
add_definitions directly in the generated build rules without attempting to escape
anything. The NEW behavior for this policy is to generate correct escapes for all
native build tools automatically. See documentation of the COMPILE_DEFINITIONS
target property for limitations of the escaping implementation.
This policy was introduced in CMake version 2.6.0. CMake version 2.8.12.2 warns
when the policy is not set and uses OLD behavior. Use the cmake_policy command to
set it to OLD or NEW explicitly.
CMP0006
Installing MACOSX_BUNDLE targets requires a BUNDLE DESTINATION.
This policy determines whether the install(TARGETS) command must be given a BUNDLE
DESTINATION when asked to install a target with the MACOSX_BUNDLE property set.
CMake 2.4 and below did not distinguish application bundles from normal executables
when installing targets. CMake 2.6 provides a BUNDLE option to the
install(TARGETS) command that specifies rules specific to application bundles on
the Mac. Projects should use this option when installing a target with the
MACOSX_BUNDLE property set.
The OLD behavior for this policy is to fall back to the RUNTIME DESTINATION if a
BUNDLE DESTINATION is not given. The NEW behavior for this policy is to produce an
error if a bundle target is installed without a BUNDLE DESTINATION.
This policy was introduced in CMake version 2.6.0. CMake version 2.8.12.2 warns
when the policy is not set and uses OLD behavior. Use the cmake_policy command to
set it to OLD or NEW explicitly.
CMP0007
list command no longer ignores empty elements.
This policy determines whether the list command will ignore empty elements in the
list. CMake 2.4 and below list commands ignored all empty elements in the list.
For example, a;b;;c would have length 3 and not 4. The OLD behavior for this policy
is to ignore empty list elements. The NEW behavior for this policy is to correctly
count empty elements in a list.
This policy was introduced in CMake version 2.6.0. CMake version 2.8.12.2 warns
when the policy is not set and uses OLD behavior. Use the cmake_policy command to
set it to OLD or NEW explicitly.
CMP0008
Libraries linked by full-path must have a valid library file name.
In CMake 2.4 and below it is possible to write code like
target_link_libraries(myexe /full/path/to/somelib)
where "somelib" is supposed to be a valid library file name such as "libsomelib.a"
or "somelib.lib". For Makefile generators this produces an error at build time
because the dependency on the full path cannot be found. For VS IDE and Xcode
generators this used to work by accident because CMake would always split off the
library directory and ask the linker to search for the library by name (-lsomelib
or somelib.lib). Despite the failure with Makefiles, some projects have code like
this and build only with VS and/or Xcode. This version of CMake prefers to pass
the full path directly to the native build tool, which will fail in this case
because it does not name a valid library file.
This policy determines what to do with full paths that do not appear to name a
valid library file. The OLD behavior for this policy is to split the library name
from the path and ask the linker to search for it. The NEW behavior for this
policy is to trust the given path and pass it directly to the native build tool
unchanged.
This policy was introduced in CMake version 2.6.1. CMake version 2.8.12.2 warns
when the policy is not set and uses OLD behavior. Use the cmake_policy command to
set it to OLD or NEW explicitly.
CMP0009
FILE GLOB_RECURSE calls should not follow symlinks by default.
In CMake 2.6.1 and below, FILE GLOB_RECURSE calls would follow through symlinks,
sometimes coming up with unexpectedly large result sets because of symlinks to top
level directories that contain hundreds of thousands of files.
This policy determines whether or not to follow symlinks encountered during a FILE
GLOB_RECURSE call. The OLD behavior for this policy is to follow the symlinks. The
NEW behavior for this policy is not to follow the symlinks by default, but only if
FOLLOW_SYMLINKS is given as an additional argument to the FILE command.
This policy was introduced in CMake version 2.6.2. CMake version 2.8.12.2 warns
when the policy is not set and uses OLD behavior. Use the cmake_policy command to
set it to OLD or NEW explicitly.
CMP0010
Bad variable reference syntax is an error.
In CMake 2.6.2 and below, incorrect variable reference syntax such as a missing
close-brace ("${FOO") was reported but did not stop processing of CMake code. This
policy determines whether a bad variable reference is an error. The OLD behavior
for this policy is to warn about the error, leave the string untouched, and
continue. The NEW behavior for this policy is to report an error.
This policy was introduced in CMake version 2.6.3. CMake version 2.8.12.2 warns
when the policy is not set and uses OLD behavior. Use the cmake_policy command to
set it to OLD or NEW explicitly.
CMP0011
Included scripts do automatic cmake_policy PUSH and POP.
In CMake 2.6.2 and below, CMake Policy settings in scripts loaded by the include()
and find_package() commands would affect the includer. Explicit invocations of
cmake_policy(PUSH) and cmake_policy(POP) were required to isolate policy changes
and protect the includer. While some scripts intend to affect the policies of
their includer, most do not. In CMake 2.6.3 and above, include() and
find_package() by default PUSH and POP an entry on the policy stack around an
included script, but provide a NO_POLICY_SCOPE option to disable it. This policy
determines whether or not to imply NO_POLICY_SCOPE for compatibility. The OLD
behavior for this policy is to imply NO_POLICY_SCOPE for include() and
find_package() commands. The NEW behavior for this policy is to allow the commands
to do their default cmake_policy PUSH and POP.
This policy was introduced in CMake version 2.6.3. CMake version 2.8.12.2 warns
when the policy is not set and uses OLD behavior. Use the cmake_policy command to
set it to OLD or NEW explicitly.
CMP0012
if() recognizes numbers and boolean constants.
In CMake versions 2.6.4 and lower the if() command implicitly dereferenced
arguments corresponding to variables, even those named like numbers or boolean
constants, except for 0 and 1. Numbers and boolean constants such as true, false,
yes, no, on, off, y, n, notfound, ignore (all case insensitive) were recognized in
some cases but not all. For example, the code "if(TRUE)" might have evaluated as
false. Numbers such as 2 were recognized only in boolean expressions like "if(NOT
2)" (leading to false) but not as a single-argument like "if(2)" (also leading to
false). Later versions of CMake prefer to treat numbers and boolean constants
literally, so they should not be used as variable names.
The OLD behavior for this policy is to implicitly dereference variables named like
numbers and boolean constants. The NEW behavior for this policy is to recognize
numbers and boolean constants without dereferencing variables with such names.
This policy was introduced in CMake version 2.8.0. CMake version 2.8.12.2 warns
when the policy is not set and uses OLD behavior. Use the cmake_policy command to
set it to OLD or NEW explicitly.
CMP0013
Duplicate binary directories are not allowed.
CMake 2.6.3 and below silently permitted add_subdirectory() calls to create the
same binary directory multiple times. During build system generation files would
be written and then overwritten in the build tree and could lead to strange
behavior. CMake 2.6.4 and above explicitly detect duplicate binary directories.
CMake 2.6.4 always considers this case an error. In CMake 2.8.0 and above this
policy determines whether or not the case is an error. The OLD behavior for this
policy is to allow duplicate binary directories. The NEW behavior for this policy
is to disallow duplicate binary directories with an error.
This policy was introduced in CMake version 2.8.0. CMake version 2.8.12.2 warns
when the policy is not set and uses OLD behavior. Use the cmake_policy command to
set it to OLD or NEW explicitly.
CMP0014
Input directories must have CMakeLists.txt.
CMake versions before 2.8 silently ignored missing CMakeLists.txt files in
directories referenced by add_subdirectory() or subdirs(), treating them as if
present but empty. In CMake 2.8.0 and above this policy determines whether or not
the case is an error. The OLD behavior for this policy is to silently ignore the
problem. The NEW behavior for this policy is to report an error.
This policy was introduced in CMake version 2.8.0. CMake version 2.8.12.2 warns
when the policy is not set and uses OLD behavior. Use the cmake_policy command to
set it to OLD or NEW explicitly.
CMP0015
link_directories() treats paths relative to the source dir.
In CMake 2.8.0 and lower the link_directories() command passed relative paths
unchanged to the linker. In CMake 2.8.1 and above the link_directories() command
prefers to interpret relative paths with respect to CMAKE_CURRENT_SOURCE_DIR, which
is consistent with include_directories() and other commands. The OLD behavior for
this policy is to use relative paths verbatim in the linker command. The NEW
behavior for this policy is to convert relative paths to absolute paths by
appending the relative path to CMAKE_CURRENT_SOURCE_DIR.
This policy was introduced in CMake version 2.8.1. CMake version 2.8.12.2 warns
when the policy is not set and uses OLD behavior. Use the cmake_policy command to
set it to OLD or NEW explicitly.
CMP0016
target_link_libraries() reports error if its only argument is not a target.
In CMake 2.8.2 and lower the target_link_libraries() command silently ignored if it
was called with only one argument, and this argument wasn't a valid target. In
CMake 2.8.3 and above it reports an error in this case.
This policy was introduced in CMake version 2.8.3. CMake version 2.8.12.2 warns
when the policy is not set and uses OLD behavior. Use the cmake_policy command to
set it to OLD or NEW explicitly.
CMP0017
Prefer files from the CMake module directory when including from there.
Starting with CMake 2.8.4, if a cmake-module shipped with CMake (i.e. located in
the CMake module directory) calls include() or find_package(), the files located in
the CMake module directory are preferred over the files in CMAKE_MODULE_PATH. This
makes sure that the modules belonging to CMake always get those files included
which they expect, and against which they were developed and tested. In all other
cases, the files found in CMAKE_MODULE_PATH still take precedence over the ones in
the CMake module directory. The OLD behaviour is to always prefer files from
CMAKE_MODULE_PATH over files from the CMake modules directory.
This policy was introduced in CMake version 2.8.4. CMake version 2.8.12.2 warns
when the policy is not set and uses OLD behavior. Use the cmake_policy command to
set it to OLD or NEW explicitly.
CMP0018
Ignore CMAKE_SHARED_LIBRARY_<Lang>_FLAGS variable.
CMake 2.8.8 and lower compiled sources in SHARED and MODULE libraries using the
value of the undocumented CMAKE_SHARED_LIBRARY_<Lang>_FLAGS platform variable. The
variable contained platform-specific flags needed to compile objects for shared
libraries. Typically it included a flag such as -fPIC for position independent
code but also included other flags needed on certain platforms. CMake 2.8.9 and
higher prefer instead to use the POSITION_INDEPENDENT_CODE target property to
determine what targets should be position independent, and new undocumented
platform variables to select flags while ignoring CMAKE_SHARED_LIBRARY_<Lang>_FLAGS
completely.
The default for either approach produces identical compilation flags, but if a
project modifies CMAKE_SHARED_LIBRARY_<Lang>_FLAGS from its original value this
policy determines which approach to use.
The OLD behavior for this policy is to ignore the POSITION_INDEPENDENT_CODE
property for all targets and use the modified value of
CMAKE_SHARED_LIBRARY_<Lang>_FLAGS for SHARED and MODULE libraries.
The NEW behavior for this policy is to ignore CMAKE_SHARED_LIBRARY_<Lang>_FLAGS
whether it is modified or not and honor the POSITION_INDEPENDENT_CODE target
property.
This policy was introduced in CMake version 2.8.9. CMake version 2.8.12.2 warns
when the policy is not set and uses OLD behavior. Use the cmake_policy command to
set it to OLD or NEW explicitly.
CMP0019
Do not re-expand variables in include and link information.
CMake 2.8.10 and lower re-evaluated values given to the include_directories,
link_directories, and link_libraries commands to expand any leftover variable
references at the end of the configuration step. This was for strict compatibility
with VERY early CMake versions because all variable references are now normally
evaluated during CMake language processing. CMake 2.8.11 and higher prefer to skip
the extra evaluation.
The OLD behavior for this policy is to re-evaluate the values for strict
compatibility. The NEW behavior for this policy is to leave the values untouched.
This policy was introduced in CMake version 2.8.11. CMake version 2.8.12.2 warns
when the policy is not set and uses OLD behavior. Use the cmake_policy command to
set it to OLD or NEW explicitly.
CMP0020
Automatically link Qt executables to qtmain target on Windows.
CMake 2.8.10 and lower required users of Qt to always specify a link dependency to
the qtmain.lib static library manually on Windows. CMake 2.8.11 gained the ability
to evaluate generator expressions while determining the link dependencies from
IMPORTED targets. This allows CMake itself to automatically link executables which
link to Qt to the qtmain.lib library when using IMPORTED Qt targets. For
applications already linking to qtmain.lib, this should have little impact. For
applications which supply their own alternative WinMain implementation and for
applications which use the QAxServer library, this automatic linking will need to
be disabled as per the documentation.
The OLD behavior for this policy is not to link executables to qtmain.lib
automatically when they link to the QtCore IMPORTEDtarget. The NEW behavior for
this policy is to link executables to qtmain.lib automatically when they link to
QtCore IMPORTED target.
This policy was introduced in CMake version 2.8.11. CMake version 2.8.12.2 warns
when the policy is not set and uses OLD behavior. Use the cmake_policy command to
set it to OLD or NEW explicitly.
CMP0021
Fatal error on relative paths in INCLUDE_DIRECTORIES target property.
CMake 2.8.10.2 and lower allowed the INCLUDE_DIRECTORIES target property to contain
relative paths. The base path for such relative entries is not well defined.
CMake 2.8.12 issues a FATAL_ERROR if the INCLUDE_DIRECTORIES property contains a
relative path.
The OLD behavior for this policy is not to warn about relative paths in the
INCLUDE_DIRECTORIES target property. The NEW behavior for this policy is to issue
a FATAL_ERROR if INCLUDE_DIRECTORIES contains a relative path.
This policy was introduced in CMake version 2.8.12. CMake version 2.8.12.2 warns
when the policy is not set and uses OLD behavior. Use the cmake_policy command to
set it to OLD or NEW explicitly.
CMP0022
INTERFACE_LINK_LIBRARIES defines the link interface.
CMake 2.8.11 constructed the 'link interface' of a target from properties matching
(IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?. The modern way to specify
config-sensitive content is to use generator expressions and the IMPORTED_ prefix
makes uniform processing of the link interface with generator expressions
impossible. The INTERFACE_LINK_LIBRARIES target property was introduced as a
replacement in CMake 2.8.12. This new property is named consistently with the
INTERFACE_COMPILE_DEFINITIONS, INTERFACE_INCLUDE_DIRECTORIES and
INTERFACE_COMPILE_OPTIONS properties. For in-build targets, CMake will use the
INTERFACE_LINK_LIBRARIES property as the source of the link interface only if
policy CMP0022 is NEW. When exporting a target which has this policy set to NEW,
only the INTERFACE_LINK_LIBRARIES property will be processed and generated for the
IMPORTED target by default. A new option to the install(EXPORT) and export
commands allows export of the old-style properties for compatibility with
downstream users of CMake versions older than 2.8.12. The target_link_libraries
command will no longer populate the properties matching
LINK_INTERFACE_LIBRARIES(_<CONFIG>)? if this policy is NEW.
The OLD behavior for this policy is to ignore the INTERFACE_LINK_LIBRARIES property
for in-build targets. The NEW behavior for this policy is to use the
INTERFACE_LINK_LIBRARIES property for in-build targets, and ignore the old
properties matching (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?.
This policy was introduced in CMake version 2.8.12. CMake version 2.8.12.2 warns
when the policy is not set and uses OLD behavior. Use the cmake_policy command to
set it to OLD or NEW explicitly.
CMP0023
Plain and keyword target_link_libraries signatures cannot be mixed.
CMake 2.8.12 introduced the target_link_libraries signature using the PUBLIC,
PRIVATE, and INTERFACE keywords to generalize the LINK_PUBLIC and LINK_PRIVATE
keywords introduced in CMake 2.8.7. Use of signatures with any of these keywords
sets the link interface of a target explicitly, even if empty. This produces
confusing behavior when used in combination with the historical behavior of the
plain target_link_libraries signature. For example, consider the code:
target_link_libraries(mylib A)
target_link_libraries(mylib PRIVATE B)
After the first line the link interface has not been set explicitly so CMake would
use the link implementation, A, as the link interface. However, the second line
sets the link interface to empty. In order to avoid this subtle behavior CMake now
prefers to disallow mixing the plain and keyword signatures of
target_link_libraries for a single target.
The OLD behavior for this policy is to allow keyword and plain
target_link_libraries signatures to be mixed. The NEW behavior for this policy is
to not to allow mixing of the keyword and plain signatures.
This policy was introduced in CMake version 2.8.12. CMake version 2.8.12.2 warns
when the policy is not set and uses OLD behavior. Use the cmake_policy command to
set it to OLD or NEW explicitly.
COPYRIGHT
Copyright 2000-2012 Kitware, Inc., Insight Software Consortium. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are
permitted provided that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list of
conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of
conditions and the following disclaimer in the documentation and/or other materials
provided with the distribution.
Neither the names of Kitware, Inc., the Insight Software Consortium, nor the names of
their contributors may be used to endorse or promote products derived from this software
without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
SEE ALSO
ccmake(1), cpack(1), ctest(1), cmakecommands(1), cmakecompat(1), cmakemodules(1),
cmakeprops(1), cmakevars(1)
The following resources are available to get help using CMake:
Home Page
http://www.cmake.org
The primary starting point for learning about CMake.
Frequently Asked Questions
http://www.cmake.org/Wiki/CMake_FAQ
A Wiki is provided containing answers to frequently asked questions.
Online Documentation
http://www.cmake.org/HTML/Documentation.html
Links to available documentation may be found on this web page.
Mailing List
http://www.cmake.org/HTML/MailingLists.html
For help and discussion about using cmake, a mailing list is provided at
cmake@cmake.org. The list is member-post-only but one may sign up on the CMake web
page. Please first read the full documentation at http://www.cmake.org before
posting questions to the list.