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
The internal tool "cmake_ninja_depends" now supports reading the list of ddi
files from a reponse file to circumvent Windows command line length limits.
Use this response file for dyndep rule on Windows.
Move the logic to cmSystemTools to be shared among the generators.
Revise the implementation and add comments justifying each possible
source for a limit.
d58d28a9 ParserHelper: Move macros to bottom of files
07953c18 remove file cmStandardIncludes.h
f918b053 cmFortranParser: include what you use
b74314c6 cmDependsJavaParser: include what you use
74404df4 cmCommandArgumentParser: include what you use
e7168c08 cmExprParser: include what you use
ee72803e fix some include-what-you-use diagnostics
We compute the location of `CMAKE_ROOT` and other resources relative to
the location of our own executable. On some platforms this path is
computed in a way that depends on the case of the path used to invoke
the executable. Convert the result to the actual case preserved by the
filesystem on disk in order to make it consistent regardless of how the
executable is launched.
This approach generalizes the fix made by commit v3.8.0-rc1~71^2
(cmSystemTools: use the actual case for root detection, 2017-01-18).
Issue: #16648
On Windows, calling a binary installed with the default `bin` binary
directory will fail to be detected when called as `BIN\cmake.exe` due to
the string compare. Get the actual case of the path before checking that
the path ends with `CMAKE_BIN_DIR`.
Fixes#16574.
Typically Windows applications (eg. MSVC compiler) use current console's
codepage for output to pipes so we need to encode that to our
internally-used encoding (`KWSYS_ENCODING_DEFAULT_CODEPAGE`).
