Move "extra" generators to their own section instead of duplicating them
for each corresponding main generator. Divide the list of main
generators into command-line and IDE sections and sort the names within
each section. Document the environment from which each kind of
generator may be used.
Add a section to each "extra" generator documenting which main
generators may be used with it.
Use definition lists instead of a preformatted block to enumerate
the genex documentation.
Consistently capitalize the description.
Use ``...`` to format genex parameters in the description.
Turn references to commands into links.
Add high level documentation about the motivation for generator
expressions.
Regroup expressions into subsections for different genex types. Add
a high-level description and example of the expressions in each
section.
Explode the documentation for filesystem artifacts, instead of only
referring to the variations.
This variable can be useful in cross-compiling contexts where the
sysroot is read-only or where the sysroot should otherwise remain
pristine.
If the new CMAKE_STAGING_PREFIX variable is set, it is used instead
of CMAKE_INSTALL_PREFIX when generating the installation rules in
cmake_install.cmake.
This way, the CMAKE_INSTALL_PREFIX variable
always refers to the installation prefix on the target device, regardless
of whether host==target.
If any -rpath paths passed to the linker contain the CMAKE_STAGING_PREFIX,
the matching path fragments are replaced with the CMAKE_INSTALL_PREFIX.
Matching paths in the -rpath-link are not transformed.
The cross-prefix usr-move workaround is assumed not to require extension
regarding CMAKE_STAGING_PREFIX. The staging area is a single prefix, so
there is no scope for cross-prefix symlinks. The CMAKE_INSTALL_PREFIX
is still used to determine the workaround path, and that variable
remains the relevant one even if CMAKE_STAGING_PREFIX is used. If the
generated export files are deployed to the target, the workaround
will still be in place, and still be employed if required.
a990722 eclipse: Support custom natures via a global property
51726cc eclipse: Add natures for Eclipse based on enabled languages
4a352d4 Notify extra generators about languages
7cd65c9 Add CMAKE_SYSROOT variable to set --sysroot when cross compiling.
5096967 Allow toolchain files to specify an external toolchain.
76552d5 Add compiler target compile options.
f41ecd1 CMakeDetermineCompilerId: Look for internal file only on host
As CMAKE_ROOT_FIND_PATH can be a list, a new CMAKE_SYSROOT is
introduced, which is never a list.
The contents of this variable is passed to supporting compilers
as --sysroot. It is also accounted for when processing implicit
link directories reported by the compiler, and when generating
RPATH information.
Clang can compile code, but uses the gcc tools for other tasks such
as linking. The -gcc-toolchain option can be used for that, but
generalize so that other compilers can be treated the same.
If such a location is specified, use it as a hint for finding
the binutils executables.
For clang, this allows passing -target <triple> to the compiler, and
for qcc, -V<arch> using toolchain files containing something like
set(triple arm-linux-gnueabihf)
set(CMAKE_C_COMPILER "/usr/bin/clang")
set(CMAKE_C_COMPILER_TARGET ${triple})
set(CMAKE_CXX_COMPILER "/usr/bin/clang++")
set(CMAKE_CXX_COMPILER_TARGET ${triple})
or
set(arch gcc_ntoarmv7le)
set(CMAKE_C_COMPILER /opt/qnx650/host/linux/x86/usr/bin/qcc)
set(CMAKE_C_COMPILER_TARGET ${arch})
set(CMAKE_CXX_COMPILER /opt/qnx650/host/linux/x86/usr/bin/QCC)
set(CMAKE_CXX_COMPILER_TARGET ${arch})
Both clang and qcc are inherently cross compiler( driver)s.
When cross-compiling with clang, use the CMAKE_${lang}_COMPILER_TARGET
as the _CMAKE_TOOLCHAIN_PREFIX to find the appropriate binutils.
When cross-compiling with QNX qcc, use the CMAKE_${lang}_COMPILER_TARGET
to set the appropriate _CMAKE_TOOLCHAIN_PREFIX.
4cce44b Help: Document the CMAKE_MAKE_PROGRAM variable in more detail
558c74d VS: Switch to internal CMAKE_MAKE_PROGRAM lookup by generators
5229f2d Tests: Do not use an explicit make program for VS generators
72dd738 Tests: Fix MFC test heuristic for empty CMAKE_TEST_MAKEPROGRAM
fd6076d Tests: Pass CMAKE_MAKE_PROGRAM instead of --build-makeprogram
68031ab Tests: Configure SubProject-Stage2 test more robustly
003d10c Tests: Simplify VSExcludeFromDefaultBuild configuration
e47d934 Tests: Simplify VSProjectInSubdir configuration
e965cb1 Tests: Simplify CTest.BuildCommand.ProjectInSubdir configuration
72bf255 Tests: Pass --build-options to every test
4d1d772 ctest: Teach --build-options to allow zero options
96966b5 ctest: Make the --build-makeprogram optional for --build-and-test
91a0211 Simplify some calls to cmGlobalGenerator::Build
123a060 Teach GenerateBuildCommand to find its own make program
5f5c92b VS: Add internal APIs to find MSBuild, devenv/VCExpress, and msdev
4ac75fd Prefer CMAKE_MAKE_PROGRAM over CMAKE_BUILD_TOOL (#14548)
...
Teach add_custom_target to check the policy too. Extend the policy to
disallow reserved target names that we use for builtin targets like
"all".
Extend the RunCMake.CMP0037 test to cover these cases.
Add notes about macro arguments in the foreach, if, and list commands.
Add a section to the macro command documentation explaining in detail
how macro arguments are not variables.
GenerateBuildCommand now knows how to lookup CMAKE_MAKE_PROGRAM or
choose a generator-provided default build tool. Therefore the
--build-makeprogram can now be optional and simply override the
default selection when provided.
Note that with --build-nocmake we now need to load the cache in order to
make the CMAKE_MAKE_PROGRAM entry available to GenerateBuildCommand.
Historically these were both added for the Makefile and Visual Studio
generators, respectively. Later the VS generators started using the
CMAKE_MAKE_PROGRAM cache entry to find the IDE build tool, and the
CMAKE_BUILD_TOOL was simply set as an alias.
Fix the documentation to explain that CMAKE_MAKE_PROGRAM is the modern
variable and that CMAKE_BUILD_TOOL is the compatibility alias, not the
other way around. Replace uses of CMAKE_BUILD_TOOL with
CMAKE_MAKE_PROGRAM in CMake-provided modules. Nothing needs to lookup
CMAKE_BUILD_TOOL in the cache, so simply set it as a normal variable.
Re-implement the build_command() command to use "cmake --build" instead
of generating a native build tool invocation directly. This command
will internally invoke the proper native build tool.
This avoids requiring cmGlobalGenerator::GenerateBuildCommand to produce
a string so that it can be later refactored to produce a vector with no
quoting or escaping. It will also allow us to later teach CMake to
delay the decision about which build tool to invoke until after the
project build system is generated to disk. For example, on Visual
Studio 10 and above the preferred command-line tool is MSBuild, but we
need to fall back to devenv if the .sln has Intel Fortran .vfproj files.
Refactor edit_cache tool selection to ask each global generator for its
preference. Teach the Ninja generator to always use cmake-gui because
Ninja by design cannot run interactive terminal dialogs like ccmake.
Teach the Makefile generator to use cmake-gui when also using an "extra"
generator whose IDE has no terminal to run ccmake, and otherwise fall
back to CMAKE_EDIT_COMMAND selection for normal Makefile build systems.
The cmake-language.7 manual now documents comment syntax. Reference it
from cmake-developer.7 when discussing how to add comment-enclosed
documentation to modules.
State in the execute_process how COMMAND arguments are passed to
the child. Add a note at the end about how the command differs
from add_custom_*().
Suggested-by: Alan W. Irwin
Apply the changes from commit 603fe925 (Fix summary documentation of
INTERFACE_LINK_LIBRARIES, 2013-11-04) and commit 0aa97b6b (Fix spelling
in INTERFACE_LINK_LIBRARIES documentation, 2013-11-04) to the new
location of the same documentation.
Stephen Kelly
Brad King
Peter Kümmel
Nils Gladitz
Ben Boeckel
Daniele E. Domenichelli
Kitware Robot