`include-what-you-use` diagnostics, in practice, are specific to
the environment's compiler and standard library. Update includes
to satisfy IWYU for our CI job under Debian 12.
This function is used by NMake Makefile generator, but when shortening path
fails, it previously returned an empty string. `ERROR_ACCESS_DENIED` is
returned for paths within `C:\Program Files\WindowsApps`, which is
a special folder with limited access rights. It looks like this is
[by design](https://superuser.com/a/1730061/213587).
Fixes: #24853
Replace WATCOMQUOTE output format by UseWatcomQuote attribute to properly handle single quote
This attribute is used globaly only for Watcom linker to handle single-quote separator instead of double-quote
it doesn't mean different output format only change of quoting separator
It is now applied to any output form SHELL/RESPONSE/NINJAMULTI if Watcom linker is used otherwise double-quote is used
UNC paths (starting with `\\`) need quotes when generating MinGW
Makefiles to avoid gmake interpreting the first `\` as an escape
character.
Fixes: #24061
Since commit c564a3e3ff (Ninja: Always compile sources using absolute
paths, 2021-05-19, v3.21.0-rc1~129^2), both the Ninja and Makefile
generators pass source files and include directories to the compiler as
absolute paths. However, in some other contexts within generated build
systems, we generate paths that may be relative or absolute. In these
contexts, we prefer relative paths, but avoid them when they contain a
`../` sequence that leaves both the build tree and the source tree:
* When the build tree is outside of the source tree, all paths to the
source tree are absolute.
* When the build tree is inside the source tree, we previously assumed
that it is a real directory such that exiting the build tree with
`../` enters the source tree. This allowed paths to the source
tree to be relative to the build tree.
In the latter case, we previously did not support using a symbolic link
inside the source tree to point at the build tree. This is because
relative paths to the source tree would be generated with `../`
sequences leaving the build tree, but they would jump to the parent of
the real build tree, which is not the source tree.
Fix this by requiring that `../` sequences stay inside the build tree
even if its path appears to be inside the source tree. When the build
tree is inside the source tree, all paths to the source tree are now
absolute. For consistency, this applies regardless of whether the
path to the build tree contains a symbolic link.
Fixes: #21819
Cache the Short Paths since we only convert the same few paths anyway
and calling `GetShortPathNameW` is really expensive.
Also, compile the code path only on Windows hosts since it only runs
when using a Windows Shell anyway.
In `ConvertToOutputForExisting` we convert paths with spaces to short
paths on Windows for use on command lines, e.g. for include directories.
Do the same for paths with `#` since tools like NMake do not have a way
to reliably put `#` in variable assignments.
Use std::string (with correct initial size) in cmOutputConverter::Shell__GetArgument
instead of ostringstream. This avoids several re-allocations of the
string buffer. In addition, convert some of the private static members into
inline free functions to avoid function calls.
* Change some functions to take `std::string` instead of
`const char*` in the following classes: `cmMakeFile`, `cmake`,
`cmCoreTryCompile`, `cmSystemTools`, `cmState`, `cmLocalGenerator`
and a few others.
* Greatly reduce using of `const char*` overloads for
`cmSystemTools::MakeDirectory` and `cmSystemTools::RelativePath`.
* Remove many redundant `c_str()` conversions throughout the code.
Port dependents to the new locations as needed.
Leave behind a cmState.h include in cmListFileCache to reduce noise. It
is removed in a following commit.
The conditional early return can be moved to clients, which would have
many benefits, notably making cmOutputConverter independent of
directory-specific state.
