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.
Our bundled third-party libraries perform many `try_compile` checks for
compatibility with their upstream build systems. For many of the checks
we already know the result for compilers we support for building CMake
itself, especially on Windows. Hard-code known results to avoid running
the checks.
GitLab now uses a `/-/` component between the `group/project` part of
the URL and the `{issues,merge_requests,tree}` part so that it can
support `group/subgroup/project` with arbitrary depth.
This script was added by commit 19f267c75e (XL: Add support for Ninja
and XL Fortran, 2019-11-21, v3.17.0-rc1~368^2) but does not have a `.sh`
extension so our existing install rules neglect to give it execute
permission. Our test suite works on XL Fortran in the build tree but
the script is broken without execute permission on installation.
Fixes: #20695
Provide our own minimal `config.h` since the upstream one is much
larger to support other parts of its distribution. Compile with
warnings disabled since this is third-party code.
This script was added by commit 0f150b69d3 (AIX: Explicitly compute
shared object exports for both XL and GNU, 2019-07-11,
v3.16.0-rc1~418^2~2) but does not have a `.sh` extension so our existing
install rules neglect to give it execute permission. Our test suite
works on AIX in the build tree but the script is broken without execute
permission on installation.
Fixes: #20520
Much like AIX, IBM i (OS identifier "OS400") implicitly adds `extern
"C"` around system header files included with the `-isystem` option.
Update the condition added by commit c688b401d3 (cmstd: Modernize CMake
system headers, 2019-08-04, v3.16.0-rc1~81^2~1) to treat `IBM i` as we
do AIX.
3ec82b713e cmMarkAsAdvancedCommand: ignore variables which don't exist in the cache
701a5c60e0 cmake: avoid marking local or unused variables as advanced
af158149e7 FindOpenSSL: do not mark a local variable as advanced
74f659f1f2 FindCurses: only mark CURSES_EXTRA_LIBRARY when it is used
7e2ae4e96d FindOpenGL: only mark declared cache variables as advanced
7cc02a0c29 FindLua: only mark LUA_MATH_LIBRARY as advanced if required
85cd26b8a6 FindBoost: only mark Boost_DIR as advanced if defined
338c7916ba CTest: avoid marking undeclared cache variables as advanced
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4150
Reconcile the changes made by:
* commit ae62f66033 (ENH: CMake does not need RPATHs at all for its own executables, 2006-03-01, v2.4.0~380)
* commit a056cffc5b (COMP: enable RPATH if any of the CMAKE_USE_SYSTEM_XXX variables is enabled, 2007-08-28, v2.6.0~1183)
* commit c0108d1e07 (COMP: use RPATH is building QtDialog and the Qt libs are not in /lib or /usr/lib, 2007-11-05, v2.6.0~915)
The overall goal of those changes was to get the RPATH set for external
libraries when needed and also to avoid re-linking or other RPATH
editing on installation. We can use a simpler approach to satisfy both
goals: always use RPATH entries for libraries found externally. If
there are no such libraries we will get no RPATH. If there are such
libraries that are not in standard paths we will get a RPATH that points
at them. This will work for running either from the build tree or the
install tree, so we can use the same for both to avoid editing on
installation.
Fixes: #20185
Provide a standardized way to handle the C++ "standard" headers
customized to be used with current CMake C++ standard constraints.
Offer under directory `cm` headers which can be used as direct
replacements of the standard ones. For example:
#include <cm/string_view>
can be used safely for CMake development in place of the `<string_view>`
standard header.
Fixes: #19491
689fdbfc61 Utilities/Release: Drop linux64 script in favor of docker build
2d7cfd30ac Utilities/Release: Drop source archive generation in scripts
facc240a45 Utilities/Release: Add docker specs to build and test Linux binaries
bf832ccf01 Utilities/Release: Add README.rst describing directory content
ab153f17bf Utilities/Release: Drop machine-specific README
ed294c1664 Add option to skip CMake tests that need network access
4b8a864d52 Add option to test CMake itself against its hosting CMake
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Gregor Jasny <gjasny@googlemail.com>
Merge-request: !3727
We removed installation of `Help/index.rst` in commit d2fde94809 (Help:
Add infrastructure for guide-level documentation, 2019-05-30), but the
file is required for `--help-full` to work. Restore installation of the
file and update it to avoid referencing the `Help/guide` directory in
its toctree during processing by `cmRST`.
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>
