They are unused, but if someone used them they would lead to
problems since they would copy the internal raw pointers
and the destructor would cause double delete
01b2d6ab74 Modernize: Use ranged for-loops when possible
15bdbec017 cmAlgorithms: Make cmRange advance/retreat safe for rvalues
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Daniel Pfeifer <daniel@pfeifer-mail.de>
Merge-request: !2901
This brings the functionality of `cmake -E create_symlink` and more to scripts.
The default behavior is to create hard links.
The `SYMBOLIC` argument can be used to create symlinks instead.
The `COPY_ON_ERROR` argument enables a fallback to copying the file in case the link fails.
The `RESULT <var>` retrieves the error message generated by the system.
It is set to "0" on success.
Fixes: #16926
The logic added by commit v3.12.0-rc1~62^2 (cmake: Teach '-E tar' to
report errors copying data, 2018-05-16) incorrectly reports failure
in the case of ARCHIVE_WARN. Convert this case to a warning.
Fixes: #18496
Found via `codespell -q 3 -I ../cmake-whitelist.txt --skip="./Utilities"`
where the whitelist consists of
```
aci
ans
behaviour
buil
convertor
dum
earch
ect
emmited
emmitted
helpfull
iff
isnt
ith
lowercased
mose
nd
nknown
nto
objext
ot
pathes
pevents
splitted
substract
superceded
supercedes
te
tim
todays
uint
upto
whitespaces
```
The allows `-E create_symlink` to work on Windows. It utilizes
`uv_fs_symlink`. I am still unsure exactly which Windows platforms will
work without requiring Administrator privileges or needing a user/group
with the "Create Symbolic Links" User Rights. It does work with my
Windows 10 Pro with Developer Mode turned on. In the test suite check
that the symlink either worked or failed with a permissions error.
Use recent changes in cmSystemTools::FileExists to check that a symlink
is broken.
Replace use of std::string allocation, std::set lookups, and toupper
conversions with explicit manual logic to do case-insensitive
recognition of a specific set of strings.
The change in commit v3.11.3~3^2 (cmSystemTools: Revert GetRealPath
implementation on Windows, 2018-05-29) broke the feature added by commit
v3.11.0-rc1~64^2 (Windows: Add support for running CMake tools through a
symlink, 2018-01-21). Use `GetRealPathResolvingWindowsSubst` in the
latter code path to restore it.
Fixes: #17882
In commit a203fcc63d (cmake: Teach '-E tar' to report errors copying
data, 2018-05-16) we introduced use of `la_ssize_t` but that was not
available until libarchive 3.3.1. Switch to the `__LA_SSIZE_T` macro
we use elsewhere.
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`. Use `clang-format` version 6.0.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
The use of `uv_fs_realpath` introduced by commit v3.11.0-rc1~445^2~1
(cmSystemTools: Implement GetRealPath on Windows, 2017-10-02) causes
`subst` drives to be expanded on Windows, breaking existing use cases.
Revert its use until an alternative implementation can be chosen.
Preserve the behavior introduced by commit v3.11.0-rc1~445^2
(cmTimestamp: For symlinks switch to timestamp of resolved path,
2017-10-02) by retaining use of `uv_fs_realpath` in a function of
a different name.
Fixes: #18033
Issue: #17206
* 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.
