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.
Since commit v2.8.12~248^2 (Ninja: Custom Command file depends don't
need to exist before building, 2013-06-07) all explicit dependencies
inside build folder were considered as possible build command
side-effects and phony rules were produced for them in case they don't
exist when starting to build. This is unnecessary since regular compile
inputs need to exist or cmake will fail. Moreover the exception for
sources having GENERATED property that can be missing is already handled
by WriteAssumedSourceDependencies.
This fixes unwanted phony rules for all regular source files when doing
in-source build, causing Ninja not complain when such files gets missing,
i.e. during development. Also this reduces number of rules in ninja.build.
Now only custom command dependencies are considered as possible side-effects.
It may happen that CMake include is an explicit dependency for some command,
while all CMake includes are set phony in WriteTargetRebuildManifest, this may
lead to duplicate phony generate rules which causes ninja warnings.
We need to remove implicit CMake includes in WriteUnknownExplicitDependencies.
This fixes FindCUDA ninja warnings.
Implement it in terms of the ComputeObjectFilenames virtual method
on the local generators.
Remove the reimplementation from the global generators which are
now all functionally identical.
Use the clang RemoveCStrCalls tool to automatically migrate the
code. This was only run on linux, so does not have any positive or
negative effect on other platforms.
Casts from std::string -> cmStdString were high on the list of things
taking up time. Avoid such implicit casts across function calls by just
using std::string everywhere.
The comment that the symbol name is too long is no longer relevant since
modern debuggers alias the templates anyways and the size is a
non-issue since the underlying methods are generated since it's
inherited.
Revert commit 4a6397a7 (Ninja: Track configured files so we can
regenerate them, 2013-06-17). The files reported by the method
cmMakefile::GetOutputFiles() must cause CMake to re-run only if they are
missing and without considering a timestamp. This is not the meaning of
the implicit dependencies field so Ninja re-runs CMake too often.
Another solution will have to be found to the original problem.
Revert commit 6fac24d7 (Ninja: Avoid re-running CMake on next build
after regeneration, 2014-01-09). The files reported by the method
cmMakefile::GetOutputFiles() must cause CMake to re-run only if they are
missing and without considering a timestamp. Therefore they cannot be
listed as outputs of the re-run rule or Ninja will re-run CMake every
time because the timestamp of configure_file outputs does not change.
Another solution will have to be found to the original problem.
In commit 4a6397a7 (Ninja: Track configured files so we can regenerate
them, 2013-06-17) we accidentally started listing files generated by
CMake as inputs to the configuration process instead of outputs from it.
Move the list of files generated by CMake to the regeneration rule
outputs section and tell Ninja to restat after running it.
Add a cmGlobalGenerator::SelectMakeProgram method to select a
caller-provided make program, the CMAKE_MAKE_PROGRAM cache entry, or a
generator-provided default. Call it from all implementations of the
GenerateBuildCommand method with the corresponding generator's default,
if any.
All cmGlobalGenerator::GenerateBuildCommand call sites that need to
produce a string now generate "cmake --build" commands. The remaining
call sites immediately pass the result to cmSystemTools::RunSingleCommand.
Avoid the intermediate string and argument parsing by directly producing a
vector of strings. Also drop the ignoreErrors argument because no call
sites remain that use it.
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.
This target type only contains INTERFACE_* properties, so it can be
used as a structural node. The target-specific commands enforce
that they may only be used with the INTERFACE keyword when used
with INTERFACE_LIBRARY targets. The old-style target properties
matching LINK_INTERFACE_LIBRARIES_<CONFIG> are always ignored for
this target type.
The name of the INTERFACE_LIBRARY must match a validity generator
expression. The validity is similar to that of an ALIAS target,
but with the additional restriction that it may not contain
double colons. Double colons will carry the meaning of IMPORTED
or ALIAS targets in CMake 2.8.13.
An ALIAS target may be created for an INTERFACE library.
At this point it can not be exported and does not appear in the
buildsystem and project files are not created for them. That may
be added as a feature in a later commit.
The generators need some changes to handle the INTERFACE_LIBRARY
targets returned by cmComputeLinkInterface::GetItems. The Ninja
generator does not use that API, so it doesn't require changes
related to that.
On windows we had a subset of the paths as unix style and a subset as windows
so when doing the set intersection it resulted in the same file being
found twice.
Fix a regression created by commit 373faae5 (Refactor how bundles and
frameworks are supported, 2013-05-05).
Since the ninja file isn't aware of how framework symlinks work, we
suppress symlink creation and let cmOSXBundleGenerator handle it. Also,
use the real name of framework library in build rules as was done
before, instead of the symlink.
When converting custom commands for the ninja build system we
need to make sure that any file dependencies that exist in the build
tree are converted to phony targets. This tells ninja that these
files might not exist when starting the build, but could be generated
during the build.
This is done by tracking all dependencies for custom command targets.
After all have been written out we remove all items from the set
that have been seen as a target, custom command output, an alias,
or a file in the source directory. Anything that is left is considered
to be a file that will be generated as a side effect of another
custom command.
Brad King
Gregor Jasny
Stephen Kelly
Peter Collingbourne
Nils Gladitz
Sylvain Joubert
Adam Strzelecki
Ben Boeckel
Robert Maynard
Peter Kümmel
Clinton Stimpson