Directory-level rules in `CMakeFiles/Makefile2` were previously
previously written by each directory's local generator using its own
decision for using relative or absolute paths.
Since commit d33b12d84b (Add support for build tree symlink inside
source tree, 2022-02-25, v3.24.0-rc1~583^2), each local generator
explicitly models the relationship between its source and build paths,
and uses this to determine when it is safe to use relative paths.
Because `add_subdirectory` supports arbitrary placement of the source
and build directories, different local generators may have different
relationships between their source and build paths. This can cause
disagreement among rules written to `CMakeFiles/Makefile2`.
Restore consistency by always using the root local generator to write
rules to `CMakeFiles/Makefile2`. Relative paths should always be
expressed w.r.t. the top-level build directory since that is the working
directory in which the `make` tool processing the file will run.
Fixes: #23814
In CMake 3.6 and below, running
cmake --build . --target "$(pwd)/SomeTarget"
with a Makefiles generator automatically converted the target
name and invoked `make SomeTarget`. This made the build command
work even though
make "$(pwd)/SomeTarget"
would fail. This behavior was not implemented for any other generators,
and does not make sense because `cmake --build` is supposed to be a thin
wrapper around the native build tool. It has also been broken since
commit 8d47a20f13 (cmOutputConverter: use new ConvertToRelativePath
signature internally, 2016-06-16, v3.7.0-rc1~90^2~1) because cmState's
relative path conversion logic is not initialized in `cmake --build`.
Remove the non-functioning code.
Most calls to `MaybeConvertToRelativePath` use one of our common work
directories (e.g. top of the build tree) as the local path. Add helpers
for each of the common cases to simplify and clarify call sites.
CMake did not specify the filename of the Makefile generated by it.
Due to GNU make precedence rules this means that the presence of a
GNUmakefile or makefile would take precedence over the generated
Makefile.
This is only relevant for in-source builds and only whenever an
alternative makefile by the above mentioned names exists.
This patch adds the (seemingly universal) `-f` switch and the
(hardcoded) filename (it is now hardcoded separately in these two
files):
- cmLocalUnixMakefileGenerator3.cxx
- cmGlobalUnixMakefileGenerator3.cxx
Fixes: #21418
This allows for setting EXCLUDE_FROM_ALL, conditional on the build
configuration. However, only the Ninja Multi-Config generator supports
different property values per config. All other multi-config
generators will yield an error in that situation.
Fixes: #20923
Previously we used `cmSystemTools::ConvertToOutputPath` which internally
used KWSys methods
* SystemTools::ConvertToUnixOutputPath
* SystemTools::ConvertToWindowsOutputPath
These were written in very early days of CMake and have some
limitations:
* They do not encode all characters. E.g. '#' is left out.
* They attempt to do some path cleanup and handle existing quotes.
These days CMake has clean unquoted paths already.
* They attempted to encode paths both for makefile targets and
for shell command lines. The latter use has mostly been replaced.
* Choosing between the two methods depends on a global variable!
Several code paths in CMake have to copy the global generator's
member ForceUnixPaths variable over to the cmSystemTools global.
Re-implement the `ConvertToMakefilePath` method to drop use of those
methods. Compute suitable makefile target path escaping and quoting
via local logic. Add support for more characters like '#'.
Fixes: #20555
Code paths that write makefile target paths use a combination of
`cmSystemTools::ConvertToOutputPath` and `cmMakeSafe`. Some were
missing the latter. Wrap these two steps up into a dedicated
`ConvertToMakefilePath` method provided on both the local and global
generators.
Since commit fbf7a92975 (Makefile: Handle '#' in COMPILE_OPTIONS,
2014-08-12, v3.1.0-rc1~174^2) we escape `#` as `\#` in `flags.make`
variable assignments so that they are not treated as a comment.
Windows-style make tools like NMake do not interpret backslashes
in that way. Other means will be needed to handle `#` in contexts
where it is even possible. The test suite is not covering this
for NMake anyway, and actually has a workaround in `Tests/TryCompile`
for the old behavior, which we can now update.
The `std::endl` manupulator, except inserting `\n` character, also
performs `os.flush()`, which may leads to undesired effects (like
disk I/O in the middle of forming data strings). For the
`std::stringstream` it also has no meaning.
The "all" target defined for a subdirectory (e.g. `cd sub; make` or
`ninja sub/all`) should not include the "all" targets from nested
subdirectories (e.g. `sub/sub`) that are marked as `EXCLUDE_FROM_ALL`.
Fix this and add a test case.
Issue: #19753
Co-Author: Sebastian Holtermann <sebholt@xwmw.org>
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
Revert the main logic change from commit 827da1119e (Makefiles: Make
build root targets "all", "clean" and "preinstall" recursive,
2019-05-17, v3.15.0-rc1~96^2~2) for the "all" and "preinstall" targets.
The commit cleaned up the Makefile generator to use the same logic for
the "all" target in the top-level directory as for subdirectories. It
exposed a long-existing bug that caused the "all" target in a
subdirectory to include the "all" targets from sub-subdirectories even
if they are marked `EXCLUDE_FROM_ALL`. The `Tests/SubDir` test should
fail but the problem is currently covered up by another bug introduced
by commit dc6888573d (Pass EXCLUDE_FROM_ALL from directory to targets,
2019-01-15, v3.14.0-rc1~83^2) that causes the "all" targets in
`EXCLUDE_FROM_ALL` subdirectories to be empty.
Revert the top-level "all" and "preinstall" targets to the old approach
to prepare to fix the latter bug without exposing the long-existing bug
at the top-level. Leave the "clean" target in the new approach because
it does not honor `EXCLUDE_FROM_ALL` anyway.
Issue: #19753
Provide a standardized way to handle the C++ "standard" headers
customized to be used with current CMake C++ standard constraints.
Offer under directory `cm` headers which can be used as direct
replacements of the standard ones. For example:
#include <cm/string_view>
can be used safely for CMake development in place of the `<string_view>`
standard header.
Fixes: #19491
Set the MinTypeNameLength option to an impossibly high value in order
to limit the diagnostics to iterators. Leave new expressions and cast
expressions for later.
This patch is generated by a python script that uses regular expressions to
search for string concatenation patterns of the kind
```
std::string str = <ARG0>;
str += <ARG1>;
str += <ARG2>;
...
```
and replaces them with a single `cmStrCat` call
```
std::string str = cmStrCat(<ARG0>, <ARG1>, <ARG2>, ...);
```
If any `<ARGX>` is itself a concatenated string of the kind
```
a + b + c + ...;
```
then `<ARGX>` is split into multiple arguments for the `cmStrCat` call.
If there's a sequence of literals in the `<ARGX>`, then all literals in the
sequence are concatenated and merged into a single literal argument for
the `cmStrCat` call.
Single character strings are converted to single char arguments for
the `cmStrCat` call.
`std::to_string(...)` wrappings are removed from `cmStrCat` arguments,
because it supports numeric types as well as string types.
`arg.substr(x)` arguments to `cmStrCat` are replaced with
`cm::string_view(arg).substr(x)`
This replaces invocations of
- `cmSystemTools::IsInternallyOn` with `cmIsInternallyOn`
- `cmSystemTools::IsNOTFOUND` with `cmIsNOTFOUND`
- `cmSystemTools::IsOn` with `cmIsOn`
- `cmSystemTools::IsOff` with `cmIsOff`
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.
In the "Unix Makefiles" generator, the `ADDTIONAL_CLEAN_FILES` directory
property was evaluated on a per target basis. This had two drawbacks:
- per directory clean files were repeated in every target clean script
- per directory clean files weren't removed in directories without targets
(issue #8164)
This patch moves the `ADDTIONAL_CLEAN_FILES` directory property processing
from the target to the directory level clean target.
Fixes: #8164 "ADDITIONAL_CLEAN_FILES directory property not respected if no
target present in directory"
