| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
The targets added by commit v3.6.0-rc1~240^2~2 (Ninja: Add `$subdir/all`
targets, 2016-03-11) use as `$subdir` the relative path from the top of
the source tree to the current source directory. This is not correct
when using `add_subdirectory(test test_bin)`. Instead we need to use
the relative path from the top of the binary tree to the current binary
directory as was done for related targets by commit v3.7.0-rc1~268^2
(Ninja: Add `$subdir/{test,install,package}` targets, 2016-08-05).
|
| |
|
|
|
|
|
|
| |
Diagnose failure to run `ninja --version` and abort early. Otherwise we
end up aborting with a confusing message about ninja version "" being
too old.
Closes: #16378
|
| |
|
|
|
|
|
|
| |
Provide a way for custom commands to inform the ninja build tool about
their implicit dependencies. For now simply make use of the option an
error on other generators.
Closes: #15479
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
With the Makefile generator one can use `cd $subdir; make install` to build and
install targets associated with a given subdirectory. This is not possible to
do with the Ninja generator since there is only one `build.ninja` file at the
top of the build tree. However, we can approximate it by allowing one to run
`ninja $subdir/install` at the top of the tree to build the targets in the
corresponding subdirectory and install them.
This also makes sense for `test`, `package`, and other GLOBAL_TARGET targets.
It was already done for `all` by commit v3.6.0-rc1~240^2~2 (Ninja: Add
`$subdir/all` targets, 2016-03-11).
|
| |
|
|
|
| |
Some test cases need features not available in Ninja < 1.6, so check the
version before running them.
|
| |
|
|
|
|
| |
Add a `CMAKE_NINJA_OUTPUT_PATH_PREFIX` variable. When it is set, CMake
generates a `build.ninja` file suitable for embedding into another ninja
project potentially generated by an alien generator.
|
| | |
|
|
|
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.
|
