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.
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.
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.
Adds a flag to indicate that pipe output from a custom command should be
interpreted as UTF-8 encoded. This change does not introduce a public
way to set the flag, but generators that create internally-generated
commands know if they are calling cmake, which uses UTF-8 pipes.
MSBuild added support for interpreting output of PreBuildEvent,
PreLinkEvent, PostBuildEvent, and CustomBuildStep as UTF-8. This change
will appear in Visual Studio 16.6 Preview 3. It is opt-in, and you need
to add the StdOutEncoding tag. MSBuild treats these as property bags so
if we emit the tag for earlier versions of Visual Studio it would be
safely ignored. This change emits the StdOutEncoding tag and sets it to
UTF-8 whenever the custom command UTF-8 pipe flag is set. This fixes
globalization issues when the output from cmake contained characters
that required MSBuild to interpret as UTF-8 before displaying them.
Arguably, many of these are bugs in `clang-tidy`. An if/else tree with
other conditionals between cloned blocks may be relying on the
intermediate logic to fall out of the case and inverting this logic may
be non-trivial.
See: https://bugs.llvm.org/show_bug.cgi?id=44165
We only use these classes with a `cmLocalUnixMakefileGenerator3`.
Construct using that type instead of just `cmLocalGenerator` so
that the Makefile-specific methods are available.
9be48c4d0b Tests: Add coverage for special characters in include directories
dc0dc974a9 Xcode: Fix quoting of paths with square brackets
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4591
Harry Mallon