In the Ninja generator we run all build rules from the top of the build
tree rather than changing into each subdirectory. Therefore we convert
all paths relative to the HOME_OUTPUT directory. However, the Convert
method on cmLocalGenerator restricts relative path conversions to avoid
leaving the build tree with a "../" sequence. Therefore conversions
performed for "subdirectories" that are outside the top of the build
tree always use full paths while conversions performed for
subdirectories that are inside the top of the build tree may use
relative paths to refer to the same files.
Since Ninja always runs rules from the top of the build tree we should
convert them using only the top-level cmLocalGenerator in order to
remain consistent. Also extend the test suite with a case that fails
without this fix.
a309409e cmOrderDirectories: Port to cmGeneratorTarget.
f83e8402 cmGeneratorTarget: Move CompileInfoMap from cmTarget.
b3f0e353 cmGeneratorTarget: Move GetCompilePDBDirectory from cmTarget.
34c43741 cmGeneratorTarget: Move GetOutputName from cmTarget.
4329a71c cmComputeLinkDepends: Port to cmGeneratorTarget.
c93230ac cmComputeLinkInformation: Port to cmGeneratorTarget.
ee26add4 cmGeneratorTarget: Move IsBundleOnApple from cmTarget.
c8a5f5ae cmMakefileTargetGenerator: Add accessor for GeneratorTarget.
f8076644 cmGeneratorTarget: Move GetLinkClosure from cmTarget.
7c809fa2 cmGeneratorTarget: Move GetLinkerLanguage from cmTarget.
6da99de3 cmGeneratorTarget: Move GetFrameworkDirectory from cmTarget.
d6bb319b cmGeneratorTarget: Move GetFullName from cmTarget.
7a460852 cmGeneratorTarget: Move GetAppBundleDirectory from cmTarget.
d560bfd2 cmGeneratorTarget: Move GetInstallNameDir* from cmTarget.
89e2a080 cmGeneratorTarget: Move GetMacContentDirectory from cmTarget.
62720e44 cmGeneratorTarget: Move GetFullNameComponents from cmTarget.
...
3b880a07 cmLocalGenerator: Require a valid cmState::Snapshot in the ctor.
e12afe76 cmState: Host some state from the cmGlobalGenerator.
c7b79aa1 cmGlobalGenerator: Require a cmake instance in ctor.
01e1cd5c cmState: Move snapshot creation to the cmake instance.
Refactor the local generator creation API to accept a
cmState::Snapshot. Adjust MakeLocalGenerator to use the 'current'
snapshot in cases where there is no parent. Create the snapshot
for subdirectories in cmMakefile::AddSubdirectory.
This means that snapshots are now created at the point of extending the tree,
as appropriate, and independently of the cmLocalGenerator and cmMakefile they
represent the state for.
In commit a390de65 (Ninja: Generate separate compile and link rules for
each target, 2015-05-18) we removed the _RSP_FILE suffix from rule names
meant for targets that need to build with a .rsp file because we now use
per-target rules anyway. Remove this suffix from references to the rule
too.
Reported-by: Herz Thomas <Thomas.Herz@kuka.com>
Our <LANG>_COMPILER and <LANG>_<TARGET_TYPE>_LINKER rule generation has
access to a specific cmTarget so the results may depend on it. Instead
generate separate rules for each target using an encoded target name.
In particular, this makes CTEST_USE_LAUNCHERS report proper target
information.
Check for CMAKE_COMPILER_IS_MINGW only after enabling a language when it
might actually be set. Previously this worked by accident because the
check for working compiler or a second language enabled would cause the
code path to be taken.
Store UsingMinGW as an instance member of cmGlobalNinjaGenerator so that
it is reset on each reconfigure. Otherwise cmake-gui cannot switch
between build trees for MinGW or non-MinGW tools.
Revert the refactoring by commit v2.8.11~105^2~1 (Ninja: use MinGW
generator code in EnableLanguage, 2013-03-09) and move the MinGW-
specific logic back to the "MinGW Makefiles" generator. Instead teach
the platform information modules for GNU and MSVC on Windows to set the
preferred RC compiler just before enabling the RC language. This way
we choose the RC compiler based on the C/C++ toolchain that is actually
enabled.
8dc3a67c cmMakefile: Out-of-line the directory methods.
0f3c8cfa cmMakefile: Use method abstraction to access directories.
b288a997 cmMakefile: Rename SetStart* directory API to SetCurrent*.
932d53bc cmMakefile: Remove redundant method duplication.
32b8f03a cmMakefile: Port users of GetStart* methods to new names.
54d6a918 cmMakefile: Rename GetCurrent{Output,Binary}Directory.
55d80d0a cmMakefile: Rename GetCurrent{,Source}Directory.
b23cf06f cmake: Remove redundant start directories.
fcf246ac cmMakefile: Populate Home directories on initialize.
8878bea7 cmake: Initialize Home directories on cmake for find-package mode.
044dc815 Use the Home directories from the cmake class where intended.
d67e8f24 cmake: Fix directory used to find the cache
1ea085d1 cmMakefile: Initialize dir definitions early.
f034bb2f Remove redundant calls to MakeStartDirectoriesCurrent.
3a68c323 cmMakefile: Fix wrong parameter names.
Extend the RunSingleCommand signature to capture stdout and stderr
separately. Allow both to be captured to the same std::string
to preserve existing behavior. Update all call sites to do this
so that this refactoring does not introduce functional changes.
66b641f4 Help: Add notes for topic 'add-GreenHills-MULTI-generator'
48004d9d Add a 'Green Hills MULTI' generator on Windows
051d8be1 cmLocalGenerator: Constify some cmTarget and cmGeneratorTarget arguments
Green Hills MULTI is an IDE for embedded real-time systems. The IDE's
product page can be found here:
http://www.ghs.com/products/MULTI_IDE.html
It supports cross compiling on ARM, Intel x86, and other architectures
with various operating systems. The IDE exists on Linux and Windows
host systems, but CMake will currently only generate the project files
on Windows host systems.
Add policy CMP0058 to avoid generating 'phony' ninja rules for unknown
custom command dependencies. This requires projects to specify their
custom command byproducts explicitly. With this requirement we no
longer have to assume that unknown custom command dependencies are
generated and can instead simply assume they are source files expected
to exist when the build starts. This is particularly important in
in-source builds. It is also helpful for out-of-source builds to allow
Ninja to diagnose missing files before running custom command rules that
depend on them.
Teach WriteUnknownExplicitDependencies to take ownership of the set of
WriteBuild outputs immediately since no other methods need the data.
This avoids re-inserting the whole set into another already populated
set.
The phony rules added by commit v2.8.12~248^2 (Ninja: Custom Command
file depends don't need to exist before building, 2013-06-07) are
circular, e.g.
build side-effect: phony side-effect
This is not diagnosed by Ninja as of version 1.5, but the dependency
does not make sense. Simply drop it and use phony rules of the form
build side-effect: phony
instead.
Reported-by: Daniel Dunbar
The Ninja build system does not support a in-file verbositiy switch.
Instead teach 'cmake --build' to extract the CMAKE_VERBOSE_MAKEFILE
setting and pass it as an optional '-v' argument to Ninja. This can
serve as a reasonable fallback.
Signed-off-by: Gregor Jasny <gjasny@googlemail.com>
Revert commit 7243c951 (Ninja: Don't limit custom cmd side-effects to
build folder, 2014-06-27) because it causes every custom command
dependency in the source tree to get a phony rule. For large projects
these rules get too big for Ninja to handle efficiently. While the
original change addressed a valid concern, it did not seem to occur
regularly in practice because well-behaved projects generate their
side-effects only in the build tree. Until we support explicit
specification of side-effects (CMake issue #14963), we will have to use
this as a middle-ground.
The pre-defined 'console' pool is a non-buffered pool that runs with a
depth of 1. CMake re-run cannot be run concurrently and it will
eventually output something. A non-buffered pool allows to get it as
soon as possible
Also, generate the minimal required version of Ninja in the build file.
Unlike with Unix Makefiles generator modifying compiler paths was not
protected with Ninja generator. It was possible to modify them in the
cache without the expected effect on the generated solution. Also
activate corresponding tests with Ninja.
Actually custom command can write wherever it wants to, such as temporary
folder or source folder, possibly violating rules that only build folder should
be affected. Therefore we should consider custom command dependency at any path
as possible side effect adding phony rule.
We avoid adding phony rules for regular source files (since the paraent
commit) so we no longer need the in-build-tree test to avoid them.