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.
e6a80ccf Make use of std::chrono throughout every component
ff62b005 CTest: add safe conversion from cmDuration to integer types
695951bc CTest: introduce cmDuration
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1592
When `cmake.exe` is executed through a symlink, `GetModuleFileNameW`
will return location of the link instead of the real path of
`cmake.exe`. This results in the following error output:
CMake Error: Could not find CMAKE_ROOT !!!
CMake has most likely not been installed correctly.
Use `cmSystemTools::GetRealPath` in `FindCMakeResources` on Windows
to resolve any symlink returned by `GetModuleFileNameW`.
This commit continues the changes made in CTest to support std::chrono
by
applying it throughout every component where a duration was used.
No functional change intended.
Since libuv commit v1.14.1~7 (win: add uv__once_init() calls,
2017-08-30) the libuv initialization of the file translate mode may take
place even if we do not use a uv loop. This change was included in our
libuv update commit f4a26c748b (libuv 2018-01-19). Therefore use of
libuv even through `cmSystemTools::GetRealPath` in any executable may
trigger its file translate mode setting.
Factor out the logic added to `cmake.exe` by commit v3.9.0-rc4~10^2
(cmake: Fix default file translate mode when using libuv, 2017-06-13)
and re-use to initialize all executables.
Issue: #16962
Fix issues diagnosed by clang-tidy [readability-non-const-parameter]
The patch separates the definitions of the function headers for the two
variants (CMAKE_USE_ELF_PARSER or not) and comments out the parameter names
to not consider them for any const-ness in the case they are actually not
even looked at.
Signed-off-by: Matthias Maennich <matthias@maennich.net>
Fix issues diagnosed by clang-tidy by pre-allocating the vector capacity
before the loop [performance-inefficient-vector-operation].
Signed-off-by: Matthias Maennich <matthias@maennich.net>
The KWSys `SystemTools::SplitProgramFromArgs` implementation goes into
an infinite loop when the value is just " " (a space). Since the
"program path with unquoted spaces plus command-line arguments"
operation it is trying to provide is poorly defined (string parsing
should not depend on filesystem content), just stop using it.
Instead consider the main two use cases the old approach tried to handle:
* The value is the name or absolute path of a program with no quoting
or escaping, but also no command-line arguments. In this case we
can use the value as given with no parsing, and assume no arguments.
* The value is a command-line string containing the program name/path
plus arguments. In this case we now assume that the command line
is properly quoted or escaped.
Fixes: #17262
