When building with the built-in Curl, CMAKE_USE_OPENSSL is only set
to ON by default if an OpenSSL installation is detected. However, this
can cause the user to mistakenly build without OpenSSL support if
OpenSSL is not installed, because CMAKE_USE_OPENSSL is set to OFF in
that case. Always set CMAKE_USE_OPENSSL to ON by default on systems
where it could be available, skipping the initial detection, resulting
in an error when we try to use OpenSSL later on. Detect this error
and advise the user to either install OpenSSL or set CMAKE_USE_OPENSSL
to OFF.
Co-Authored-by: Brad King <brad.king@kitware.com>
An old workaround for `std::allocator_traits<>::value_type` lints from
IWYU on `std::vector<>` usage breaks IWYU's handling of `<memory>`.
Convert the workaround to use the same approach we already use for a
workaround of `std::__decay_and_strip<>::::__type` lints. Then update
the `<memory>` inclusions to follow the now-correct IWYU lints.
The `F_BARRIERFSYNC` constant was not added until the macOS 10.11 SDK.
Hard-code its value instead. This approach is backported from upstream
libuv PR 2334.
* Deprecation removals previously specific to MSVC/Intel now also used
by clang
* String literals were assigned to non const pointers. These are stored
in mutable arrays now
* An implicit function pointer to pointer conversion is a Microsoft
extension warning is suppressed by an explicit reinterpret_cast
* The MSVC specific deprecation macro for jsoncpp was moved after the
clang macro to avoid redefinition warnings. This is consistent with
how jsoncpp fixed the issue in 36d8cfd7
Replace the `upload_release.cmake` script with a `push.bash` script
that is more configurable from the command line and that does not
hard-code any destinations. Instead of using `scp` to access
`cmake.org` directly, push the files atomically to a staging
directory from which another process will actually upload them.
6c81c6538b libarchive: avoid b64_encode name conflict with Solaris built-in function
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3351
b783e62533 cmExecuteProcessCommand: Port to cmArgumentParser
9bddb03f31 cmParseArgumentsCommand: Port to cmArgumentParser
45edf1ad66 Retire cmCommandArgumentsHelper
f5acecaa6f cmExportCommand: Port to cmArgumentParser
e6b6bb0618 cmInstallCommand: Port to cmArgumentParser
4336a29edd cmFileCommand: Port to cmArgumentParser
4359fe133b Introduce cmArgumentParser
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Leonid Pospelov <pospelovlm@yandex.ru>
Merge-request: !3137
Our nightly and release binaries build in an environment that does not
support these instructions. Disable them everywhere for simplicity
because CMake's application of this library is not performance-critical.
Although the upstream has a CMake build system, it is meant for the
complete package. Add a simple one to build just the static library
we need within CMake.
Since commit 5b9da05b7a (Windows: Embed version information into CMake
binaries, 2017-10-25, v3.11.0-rc1~411^2) our binaries have version
information that prevents a `.msi` downgrade from replacing them by
default. Configure the re-install mode:
* a: reinstall all files regardless of version
* m: rewrite all per-machine registry entries
* u: rewrite all per-user registry entries
* s: reinstall shortcuts and icons
Fixes: #19006
In commit e903a9fc55 (Utilities/Release: Create a Windows 64-bit binary,
2016-03-16, v3.6.0-rc1~235^2~2) we added a `_USING_V110_SDK71_` macro to
tell the MSVC standard library headers they were using an older SDK.
The environment in which our Windows binaries are produced has been
updated to use a Windows 10 SDK now that we do not need to support
WinXP, so we can drop the definition.
In commit beb991110d (Remove now-unused code once used on IRIX,
2019-01-11, v3.14.0-rc1~167^2) we removed remnants of IRIX support.
Also remove remnants of MIPSpro compiler support.
Cristian Adam