Our vendored curl only enables the Secure Transport backend by default
(`CURL_SSL_BACKEND=secure-transport`), but it is limited to TLS 1.2.
The macOS SDK provides the curl development components, and the
corresponding `libcurl.4.dylib` runtime library comes with macOS.
On macOS 12 and above, the default `CURL_SSL_BACKEND=openssl`
backend seems to be capable of selecting TLS 1.3 at runtime for
https connections.
Unfortunately the macOS version of curl, even on macOS 14.4, does
not accept `CURL_SSLVERSION_TLSv1_3` at runtime to enforce TLS 1.3.
However, while our vendored curl accepts the option and passes it
to Secure Transport, macOS does not actually enforce it anyway.
Fixes: #25870Fixes: #23701
- Depends on cppdap and jsoncpp.
- Add --debugger argument to enable the Debugger.
- Add --debugger-pipe argument for DAP traffics over named pipes.
- Support breakpoints by filenames and line numbers.
- Support exception breakpoints.
- Call stack shows filenames and line numbers.
- Show Cache Variables.
- Show the state of currently defined targets,
tests and directories with their properties.
- Add cmakeVersion to DAP initialize response.
- Include unit tests.
Co-authored-by: Ben McMorran <bemcmorr@microsoft.com>
Since commit 9199f7c627 (Disable arch-specific try_run in CMake itself,
2009-12-14, v2.8.2~567) we've abused an undocumented debugging feature
to override the builtin `try_run` command in CMake's own build with a
wrapper macro. However, we've also long discouraged use of this feature
by other projects. The purpose of the original change is outdated and
of limited use anyway, so just drop it.
The macro was one time used with the comment "Simply to improve readability...".
The result file doesn't have a macro anymore and just included into
the root `CMakeLists.txt`.
Take advantage of policy CMP0077 NEW behavior to hard-code settings,
defined by `option()` calls in upstream libarchive, without adding
them to our cache.
In particular, guarantee that policy `CMP0077` has `NEW` behavior.
This will be useful to hard-code options of third-party libraries
without polluting our own cache.
The %f specified extends the string(TIMESTAMP) and file(TIMESTAMP)
commands to output the timestamp with a microsecond resolution.
This convention is offered by python's datetime module.
Before, the precision was limited to seconds.
The implementation is done by extending existing cmTimestamp methods
with a `microseconds` parameter. This parameter is optional in order to
be backwards compatible. The timestamps are now received in a
cross-platform manner using libuv, since the standard C functions like
time() don't allow for sub-second precision.
This requires libuv 1.28 or higher. We already require higher than
that on Windows, so update the required version for other platforms.
Implements: #19335
Due to MCST LCC compiler identification is now changed to LCC,
there should be a way for old projects to still identify it as GNU,
as it was before.
This commits adds the policy:
CMP0129: Compiler id for MCST LCC compilers is now LCC, not GNU.
This policy controls such a behavior.
OLD behaivior is to treat LCC as GNU, NEW is to treat is as LCC.
02b2607a5c Help: Add release note for MCST LCC compiler support
e5d9fce03f LCC: Add dedicated support for MCST LCC compiler
2b9ef77944 CPack/DEB: deal with broken dpkg-shlibdeps on E2K architecture
0995c75301 Tests/RPM: skip tests tat rely on debugedit if it's not found
ea55ac9a51 Tests/RunCMake/CommandLine: Deal with locales that are different from English
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6608
Divert LCC compiler as a new one, instead of treating it as GNU.
Since old times, Elbrus C/C++/Fortran Compiler (LCC) by MCST has been
passing checks for GNU compilers, so it has been identified as GNU.
Now, with intent of seriously upstreaming its support, it has been
added as a separate LCC compiler, and its version displays not a
supported GCC version, but LCC version itself (e.g. LCC 1.25.19 instead
of GNU 7.3.0).
This commit adds its support for detection, and also converts basically
every check like 'is this compiler GNU?' to 'is this compiler GNU or
LCC?'. The only places where this check is untouched, is where it
regards other platforms where LCC is unavailable (primarily non-Linux),
and where it REALLY differs from GNU compiler.
Note: this transition may break software that are already ported to
Elbrus, but hardly relies that LCC will be detected as GNU; still such
software is not known.
I noticed that I wasn't getting any compiler warnings when testing my
merge requests locally. Turns out this happens because I am compiling
using Clang rather than GCC, so no warning flags are added to the build.
d06a9bdf3a enabled warnings by default
for GCC > 4.2, but Clang supports them too. This has been the case
since at least Clang 3.0 (I couldn't test any older versions on
godbolt.org). For AppleClang, we can also assume that the warning flags
are supported. According to Wikipedia Clang became the default
compiler starting with Xcode 4.2, and the table on
https://trac.macports.org/wiki/XcodeVersionInfo, states that XCode
4.2 Clang was based on upstream Clang 3.0, which supports all the
warning flags.
The warning flags are currently not added when compiling with clang-cl
since this exposes some pre-existing warnings that need to be fixed first.
In commit 7f89053953 (cmSystemTools: Return KWSys Status from CreateLink
and CreateSymlink, 2021-04-15) we just took the `-err` from libuv and
treated it as a POSIX error. This is accurate on POSIX, but on Windows
does not match the POSIX error codes.
Use `uv_fs_get_system_error` to get the actual system error code.
This requires libuv 1.38 or higher. Require that for Windows, but
fall back to the previous approach on POSIX.
