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.
Headers in `uv/` can include each other without the `uv/` prefix. Using
the prefix assumes that the location of `uv/` is in the include file
search path, but it is possible to include `uv.h` via a longer path.
Clang's ubsan (-fsanitize=undefined) reports:
runtime error: negation of -9223372036854775808 cannot be represented in
type 'Json::Value::LargestInt' (aka 'long'); cast to an unsigned type to
negate this value to itself
Follow its advice and update the code to remove the explicit negation.
Backport upstream curl commit 2c5ec339ea (Curl_follow: accept
non-supported schemes for "fake" redirects, 2018-11-01) to get
a fix to curl issue 3210, a regression in 7.62.0.
0310024563 curl: Update build within CMake to account for 7.61 changes
b9d1107790 curl: Backport to work with CMake 3.1 again
e9e8dcee6b Merge branch 'upstream-curl' into update-curl
18812a9c3d curl 2018-09-04 (432eb5f5)
ded211ae46 curl: Update script to get curl 7.61.1
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2509
When generating `curl_config.h`, add size information for `long long`
and `__int64` types. These are needed as candidates for defining the
`ssize_t` type because on MSVC, `long` is not the same size as `size_t`.
This problem did not affect upstream curl because it computes the
`ssize_t` type in CMake code where all sizes are available. CMake's
port computes it in preprocessor logic because universal binaries on
macOS do not know type sizes until compile time.
Fixes: #18477
The_CURL_STATICLIB option was replaced by BUILD_SHARED_LIBS.
Drop our own CURL_STATICLIB compile definition because it is now
provided by curl's usage requirements.
Curl 7.61.1 requires CMake 3.4 to build from source and also exposes
a dependency on OpenSSL imported targets. Revert that part of the
changes imported from curl upstream.
93f3f65516 Help: Revise docs of modules AddFileDependencies..CheckFunctionExists
fc7ee1ca45 Help: Override pygments CMakeLexer to support <..> and [..]
74b3eacdc7 Help: Use appropriate list types in FindPkgConfig
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2468
* The code snippets in the docs consist of CMake code mixed
with syntax definition punctuation like < > [ ] ... Therefore
a pure CMake lexer is inadequate. Here it is replaced by a
CMake syntax definition parser.
* Fixed syntax definition snippets in FindPkgConfig.cmake to
make best use of syntax highlighting. This source file is the
hardest to support because it contains comparison operators
<= = >=, which need special attention to avoid confusion
with the placeholder indicators <...>.
* Fixed syntax in execute_process.rst (there were unbalanced
brackets).
* Disabled syntax highlighting for long string examples in
cmake-language.7.rst.
* No highlighting of removed syntax in CMP0049
* To inspect the outcome of this patch, see e.g. the pages
* manual/cmake-buildsystem.7.html
* module/ExternalProject.html
* module/FindPkgConfig.html
which are particularly rich in complex code snippets.
CMake 3.12 introduced a `...<max>` syntax in the version given to
`cmake_minimum_required` to automatically set policies to NEW up
to that version. Use it to avoid listing policies explicitly.
The syntax is compatible with older versions of CMake such that they use
the extended version string for the `CMAKE_MINIMUM_REQUIRED_VERSION`
variable (which we don't use) but otherwise ignore it.
