d14349c907 ci: Enable ISPC tests on Linux, Windows, and macOS nightly builds
49996faaac ci: remove ISPC from the Fedora CI image
3e791592ad gitlab-ci: init macOS and Windows jobs with per-CMAKE_CONFIGURATION scripts
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7336
Revert commit 5ece12b7e4 (gitlab-ci: add ISPC to the Fedora CI image,
2020-08-18, v3.19.0-rc1~244^2). Later we will download ISPC in specific
jobs.
Update a `RunCMake.NinjaMultiConfig` test expectation to account for
a change to the Qt deployed on Fedora 36.
Apply the approach from commit 747940157f (gitlab-ci: init environment
with per-CMAKE_CONFIGURATION shell scripts, 2021-03-12,
v3.21.0-rc1~480^2~4) to macOS and Windows too.
Add three tests in Tests/RunCMake/PrintHelpers, meant to verify
basic functionality of the module. Tests are:
* Variables: Test the results of a cmake_print_variables()
call on two variables set within the test script.
* Properties: Test cmake_print_properties() calls on a pair
of SOURCES and a pair of TARGETS, printing some basic properties.
* PropertiesSources: Specifically verify the results of a
cmake_print_properties() call for the SOURCES property of a
TARGET. Prior to the fix introduced alongside these tests, it
was a known bug that such a request caused a FATAL_ERROR.
It's been a long-standing bug in CMakePrintHelpers that the
cmake_print_properties() function cannot print the SOURCES
property of a requested TARGET, confusing it with a request
to print properties of SOURCES.
We work around this by parsing the arguments in two stages,
so that a SOURCES that comes after the PROPERTIES keyword
is handled differently from a SOURCES that comes before it.
This adds the restriction that the "mode" keyword (TARGETS
SOURCES DIRECTORIES etc...) and its arguments **must** precede
the PROPERTIES keyword and its arguments. In other words:
1. Both of these are now valid and will be interpreted correctly,
whereas previously only the first was, and the second caused
a FATAL_ERROR:
cmake_print_properties(SOURCES foo.c PROPERTIES LANGUAGE)
cmake_print_properties(TARGETS foo PROPERTIES SOURCES)
2. This, OTOH, which used to be valid, no longer is, and will
trigger a FATAL_ERROR:
cmake_print_properties(PROPERTIES LANGUAGE SOURCES foo.c)
Fixes: #14883
We previously defined `_POSIX_C_SOURCE` and friends while building
binary packages in order to minimize the version of glibc needed at
runtime. The definitions were added by commit facc240a45
(Utilities/Release: Add docker specs to build and test Linux binaries,
2019-08-23, v3.16.0-rc1~184^2~2), but came from older packaging scripts
that were removed by commit 689fdbfc61 (Utilities/Release: Drop linux64
script in favor of docker build, 2019-08-27, v3.16.0-rc1~184^2). Those
older scripts were meant for use in a hand-maintained environment. Now
that we use base images of old CentOS versions to establish the build
environment, our builds are already limited to older glibc versions
(glibc 2.12 from centos6 on x86_64, and 2.17 from centos7 on aarch64).
Our old system API definitions no longer affect the glibc version
required by the binaries. Drop them to avoid potential conflicts with
system API definitions added by changes like commit f034b0f663 (CMake
compilation: do not use compiler extensions, 2020-03-14, v3.18.0-rc1~494^2)
and commit c7c3e39e4f (Utilities: Activate POSIX APIs even without
compiler extensions, 2022-06-02).
c7c3e39e4f Utilities: Activate POSIX APIs even without compiler extensions
3ba324b6b6 libarchive: Remove a system preprocessor macro that conflicts with a local var
4a283fcc31 librhash: Explicitly enable large file support on 32-bit targets
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !7320
With CMP0128 OLD compiler extensions are enabled by default regardless of the
compiler's default.
Fix the test to always check for the extension flag as it was intended to.
Fixes: 4a0485be7f (cmStandardLevelResolver: Avoid
unnecessary flags, fix unset level logic, 2021-04-29)
Compile some third-party libraries with preprocessor definitions that
activate POSIX APIs even when compiler extensions are not enabled.
We already do this in libuv, inherited from the upstream buildsystem.
This extends commit f034b0f663 (CMake compilation: do not use compiler
extensions, 2020-03-14, v3.18.0-rc1~494^2).
Issue: #20454
On SunOS i386, the system headers sometimes define macro names
corresponding to register names, short and with no prefix.
Undefine one that conflicts with our code.
In certain specific scenarios, it is possible to end up with JAVA_COMPILE
being unset, but Java_JAVAC_EXECUTABLE being set. This typically occurs
when running different versions of CMake in the same build directory
without deleting the CMakeCache.txt each time. This can result in an
obscure error about the wrong number of arguments to the
get_filename_component() command, but the real cause is the
JAVA_COMPILE variable being unset.
The JAVA_COMPILE variable is only set by the FindJava module, and it
is a legacy variable that has been superceded by Java_JAVAC_EXECUTABLE.
The latter is what the if() expression tests, so use that same variable in
the body of the if() block for consistency and to avoid the above problem.
Projects should always have specified one of PRE_BUILD, PRE_LINK or
POST_BUILD, and the documentation has always shown that one must
be given. But the argument parsing logic was such that if none was given,
POST_BUILD would be used and no error or warning would be raised.
Projects may be relying on this behavior, so document it as formally
supported, but not recommended.
Fixes: #23488
