| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |/ /
| | |
| | |
| | | |
Fixes: #21267
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Early versions of the Ninja Multi-Config generator required
CMAKE_CONFIGURATION_TYPES and friends to be cache variables in order
to support selecting the default config in cmake(1) --build. The
behavior of cmake(1) --build has since been updated to no longer
require this, and requiring these variables to be cache variables is
inconsistent with the other generators.
Read the variables as normal CMake variables like the other generators.
This does not require a policy, since the only scenario where this would
cause a breakage is one where the cache variable and the CMake variable
are explicitly set to different values, which doesn't make sense to do
anyway.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
#pragma once is a widely supported compiler pragma, even though it is
not part of the C++ standard. Many of the issues keeping #pragma once
from being standardized (distributed filesystems, build farms, hard
links, etc.) do not apply to CMake - it is easy to build CMake on a
single machine. CMake also does not install any header files which can
be consumed by other projects (though cmCPluginAPI.h has been
deliberately omitted from this conversion in case anyone is still using
it.) Finally, #pragma once has been required to build CMake since at
least August 2017 (7f29bbe6 enabled server mode unconditionally, which
had been using #pragma once since September 2016 (b13d3e0d)). The fact
that we now require C++11 filters out old compilers, and it is unlikely
that there is a compiler which supports C++11 but does not support
#pragma once.
|
| | |
|
|/ |
|
|
|
|
|
|
| |
And add an "install:all" target.
Fixes: #20713
|
|
|
|
| |
Fixes: #20621
|
|
|
|
|
|
| |
We may want to enable these variables later on with specific
semantics. To avoid breaking backwards compatibility, make it an
error to use them for now.
|
|
|
|
|
|
|
|
| |
Prior to this fix, CMAKE_NMC_DEFAULT_CONFIGS would inherit "all" from
the union of CMAKE_NMC_DEFAULT_BUILD_FILE_CONFIG and
CMAKE_NMC_CROSS_CONFIGS. This is inconsistent with the behavior of the
"all" target signifying CMAKE_NMC_CROSS_CONFIGS. Update "all" in
CMAKE_NMC_DEFAULT_CONFIGS to inherit only from CMAKE_NMC_CROSS_CONFIGS.
|
|
|
|
| |
And give other generators a path forward to add support in the future.
|
|
|
|
|
|
| |
If cmake --build is called with no --config argument, and a
build.ninja file is available, use that instead of defaulting to the
Debug config.
|
|
|
|
|
|
| |
Remove redundant variable CMAKE_NINJA_MULTI_CROSS_CONFIG_ENABLE.
Rename other variables. Document and improve handling of error
conditions.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Many users will want to use the Ninja Multi-Config generator like a
traditional Visual Studio-style multi-config generator, which doesn't
mix configurations - custom commands are built using target executables
of the same configuration the command is for. We do not want to force
these people to generate an N*N build matrix when they only need N*1,
especially if they have lots of targets. Add a new variable,
CMAKE_NINJA_CROSS_CONFIG_ENABLE, to opt-in to the cross-config build
matrix.
|
|\
| |
| |
| |
| |
| |
| |
| | |
fb18215904 Ninja: clean ninja metadata once generated
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Jan Niklas Hasse <jhasse@bixense.com>
Merge-request: !3316
|
| |
| |
| |
| | |
Fixes: #15830
|
|/ |
|
| |
|
|
|
|
| |
Co-Authored-by: vector-of-bool <vectorofbool@gmail.com>
|
| |
|
| |
|
|
|
|
|
| |
Run the `clang-format.bash` script to update our C and C++ code to a new
include order `.clang-format`. Use `clang-format` version 6.0.
|
|
|
|
|
| |
Remove its dedicated implementation and update the per-directory "all"
target generation to work for the top-level directory too.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
Resolve conflicts with changes since the 3.15 series:
* Convert `cmSystemTools::IsOn` => `cmIsOn`.
* Move one "EXCLUDE_FROM_ALL" target property logic fix to
its new location in `cmMakefile::AddNewUtilityTarget`.
|
| |\ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The "all" target in each directory is supposed to have targets from that
directory even if the directory itself is marked `EXCLUDE_FROM_ALL` in
its parent. This was broken by commit dc6888573d (Pass EXCLUDE_FROM_ALL
from directory to targets, 2019-01-15, v3.14.0-rc1~83^2) which made the
participation of a target in "all" independent of context. Revert much
of the logic change from that commit to restore the old behavior. Then
re-implement the behavior intended by the commit to keep its test
working. Extend the test to cover the old behavior too.
Fixes: #19753
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Automate the conversion with
perl -i -0pe 's/typedef ([^;]*) ([^ ]+);/using $2 = $1;/g'
then manually fix a few places.
|
| | |
| | |
| | |
| | |
| | | |
Upstream Ninja 1.10 and above support the `dyndep` feature we need
for Fortran.
|
| | |
| | |
| | |
| | |
| | |
| | | |
Our dyndep support version 1 has been merged to upstream Ninja.
We never developed a second dyndep version, so simply drop our
checks for different versions.
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| | |
An old workaround for `std::allocator_traits<>::value_type` lints from
IWYU on `std::vector<>` usage breaks IWYU's handling of `<memory>`.
Convert the workaround to use the same approach we already use for a
workaround of `std::__decay_and_strip<>::::__type` lints. Then update
the `<memory>` inclusions to follow the now-correct IWYU lints.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Instead of passing multiple strings to the `WriteRule` and `AddRule` methods
of `cmGlobalNinjaGenerator`, pass only a `cmNinjaRule` instance reference,
that is set up beforehand.
Adapt calls to `WriteRule` and `AddRule` in multiple places.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
b5bf369ec6 Release notes: Add release notes for ADDITIONAL_CLEAN_FILES properties
4e2ce0a67a Doc: Update and deprecate ADDITIONAL_MAKE_CLEAN_FILES directory property
338994d65d Doc: Add documentation for ADDITIONAL_CLEAN_FILES properties
c11f089d73 Tests: Extend MakeClean test to cover ADDITIONAL_CLEAN_FILES
012d599e26 Ninja: Add support for ADDITIONAL_CLEAN_FILES target property
890a1b9dc3 Ninja: Add support for ADDITIONAL_CLEAN_FILES directory property
7b23001f20 Ninja: Add support for additional clean files
d745df4b01 Makefiles: Add support for ADDITIONAL_CLEAN_FILES target property
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3318
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Additional clean files for the Ninja generator can be registered
via the new method `cmGlobalNinjaGenerator::AddAdditionalCleanFile`.
If there are additional clean files, a new rule `CLEAN_ADDITIONAL` and
a new build target `CMakeFiles/clean.additional` get generated.
The `clean` target will depend on `CMakeFiles/clean.additional`, if the target
exists.
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | | |
9f76961de8 Support job pools in custom commands and targets
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3308
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Provide a way for custom commands and targets to set the pool variable
of the ninja build statement. Setting `JOB_POOL` is not compatible with
`USES_TERMINAL`, which implies the `console` pool.
The option is silently ignored with other generators.
Closes: #18483
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
A convenience `clean` target for the Ninja generator exists since commit
3bd41f2eb5. It's safe to call `ninja clean` instead of `ninja -t clean`.
This removes the exception mapping of the `clean` target in
`cmake --build ... --target clean` calls to the Ninja `-t clean` tool.
|
| | | |
|
| | | |
|
|/ /
| |
| |
| |
| | |
- Use `std::unordered_set` for the emitted rule register
- Use `std::unordered_map` for command length register
|