2808281730 gitlab-ci: update cmake.org documentation in release package pipeline
ed00a29cce gitlab-ci: consolidate jobs for cmake.org/cmake/help/git-{master,stage} docs
5c2e8ce515 Utilities/Sphinx: Add OpenSearch link to html page headers on cmake.org
a14905d4df Utilities/Sphinx: Add option to build outdated version banner for cmake.org
cca73b54ae Utilities/Sphinx: Add undocumented option to build docs for cmake.org
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7144
Reference an OpenSearch description file that sits outside the content
of any specific version so we only need to maintain one and so that
it can reference the latest version.
This was previously added in a custom branch for building the
cmake.org reference documentation.
Revise the spec added by commit ff929badb3 (Utilities/Release: Add
docker specs to build and test Windows binaries, 2020-05-05,
v3.18.0-rc1~203^2~1) to add a `source` stage that stops just after
copying the source tree into the image. This provides more granular
control to driving scripts.
libarchive's crypto library checks use its `config.h` inside the
`try_compile` project. Since commit ade3b16e63 (libarchive: Use KWIML
to get fixed-size integer types, 2020-06-01, v3.18.0-rc1~33^2),
that header depends on KWIML inside CMake. Add the include directory
for KWIML to the crypto library checks. Otherwise, they always fail
due to not finding the KWIML headers, and libarchive decides not
to link the crypto library.
libarchive has other code besides the hash algorithms that depends on
the crypto library if its ENABLE_OPENSSL option is enabled (which in
CMake is controlled by CMAKE_USE_OPENSSL). It seems to be missing some
conditions to link the crypto library in those cases, and instead relies
on at least one of the above-mentioned checks to pass. If they all
fail, and we are using system curl, we might not link the crypto
library.
Fixes: #23234
Previously we used a complicated heuristic to decide whether or not to
run the MFC test, but it sometimes decided incorrectly to run the test.
Since that was first written, we have developed a convention for other
tests to enable them via undocumented cache entries that are added only
on machines known to meet the tests' requirements. Do that for MFC.
e674e02c55 Help: Add release note for experimental ccmake support on Windows
5c9310c714 ci: Enable ccmake on Windows
9278c6e01a ccmake: Add Windows support using PDCurses
b97c12babb ccmake: Refactor resizing logic into cmCursesForm
bf11dab49d ccmake: Refactor BUILD_CursesDialog option logic
bf94e01348 cmpdcurses: Add CMake build system
89703bc941 Merge branch 'upstream-PDCurses' into update-pdcurses
f84c4112c3 PDCurses 2021-12-08 (f1cd4f45)
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6832
Since commit ee68d3eb8c (jsoncpp: Add script to update from upstream,
2017-08-28, v3.10.0-rc1~199^2~8) we use a script to maintain the jsoncpp
vendor branch. Drop our readme that documented the old approach.
The `check_type_size(ssize_t SIZEOF_SSIZE_T` call in cmcurl (referenced
by the comment above) defines `HAVE_SIZEOF_SSIZE_T` and not
`HAVE_SSIZE_T`. The `HAVE_SSIZE_T` variable *might* get defined, but
via the `CHECK_TYPE_SIZE(ssize_t SSIZE_T)` call in cmlibarchive, which
would be configured *after* cmnghttp2, and so the first configure would
lead to an invalid `cmnghttp2/config.h` file.
Since commit 4ef974e6cb (CPack: Remove undocumented deprecated OSXX11
generator, 2021-11-05), the `CPack.OSXScriptLauncher.in` binary is no
longer installed in the `CMake.app` bundle, so it does not need to be
signed.
We produce macOS binaries for `cmake.org` using GitLab CI jobs.
Binaries for official releases are additionally signed and notarized
manually by a maintainer with suitable signing certificates and Apple
developer account credentials. Add a script to drive these steps.
Using the real `tcp.c` simplifies `cmake-bootstrap.c`, and its
implementation doesn't seem to require any of the platform-specific
definitions. Also, later it will be needed for `uv_socketpair`.
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.
