Java.NativeHeaders test was not passing on
t:fedora36-ninja-multi pipeline. This is due to
paths being not set because of $<CONFIG> being used
at --test-command, but not being used at the actual
CTest invocation.
Now the correct variable is used there.
OS Elbrus 6.0-rc1 to rc3 have hg executable broken
because of python2 and python3 module directories conflict.
Here, we avoid hg related tests if such case is detected.
Java RVM on E2K architecture is known to be broken
prior to RVM version 3.5.2 (they crash with SIGILL
in some circumstances). That disallows tests like
Java.Javah, Java.Jar, and Java.NativeHeaders to pass.
Now, if such RVM is detected, these test are not being run.
OS Elbrus 6.x has totally broken dpkg-shlibdeps; 7.1 has
a working one, but still no symbols/shdibdeps files, so
generated dependencies are also empty. Since this commit,
we're checking if these files exist, and if not, we skip
the CPackComponentsDEB-components-depend2 test.
There are distros (OS Elbrus 6.x, 7.x, Ubuntu 21.x)
where javac is a recurse symlink, like /usr/bin/javac ->
/etc/alternatives/javac -> /usr/lib/jvm/.../bin/javac.
On these distros, Java tests were not run, because
Tests/CMakeLists.txt was not able to handle this case
correctly. Now an additional stage of resolving symlinks
is added, and these distros have Java tests running.
Some distros (OS Elbrus less than 7.0) have unrunnable
makensis. While performing tests, this condition is now
checked, and NSIS CPack generator test is not performed.
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.
Add a `CMAKE_WATCOM_RUNTIME_LIBRARY` variable to control the
runtime library selection. Add policy CMP0136 to switch to
in place of the old hard-coded default flags.
Fixes: #23178
Occasionally one of the `CTest.UpdateBZR` tests fails with:
bzr: ERROR: [...] File exists: '/.../Tests/CMakeFiles/TestHome/.bazaar'
Create the directory ahead of time to eliminate any chance of a
time-of-check-time-of-use race.
These tests have not been automatically enabled on current
versions of `bzr` in a long time. The recent change to
drop the `xmlplugins` heuristic caused the tests to start
running on some machines, but they do not work everywhere.
Disable the tests again pending further investigation.
Add undocumented `CMake_TEST_ExternalProject_*` cache entries to
explicitly enable or disable these tests. If not set, compute defaults
as before. Also consolidate the VCS default heuristics.
Since commit b819ee85c0 (BUG: Oops. Left chunk of junk at the bottom of
the main Tests CMakeLists.txt file..., 2009-07-24, v2.8.0~385) the
`do_cvs_tests` variable is not used in `Tests/CMakeLists.txt`.
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.
Link line construction starts with `LINK_LIBRARIES` and appends
dependencies from the transitive closure of `INTERFACE_LINK_LIBRARIES`.
Only the entries of `LINK_LIBRARIES` are considered direct link
dependencies. In some advanced use cases, particularly involving static
libraries and static plugins, usage requirements need to update the list
of direct link dependencies. This may mean adding new items, removing
existing items, or both.
Add target properties to encode these usage requirements:
* INTERFACE_LINK_LIBRARIES_DIRECT
* INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE
Fixes: #22496
A couple of VS tests were conditioned on `NOT CMAKE_GENERATOR_TOOLSET`,
but in CI jobs with VS we always set `CMAKE_GENERATOR_TOOLSET`. Make
the condition specific to excluding the `v90` toolset, which was its
original intention anyway.
Revert commit b284a21fee (VS: Add missing label in C# project-build
events, 2021-09-03, v3.22.0-rc1~156^2). The change broke cases using
multiple successful custom commands. Revert it pending further
investigation into the interaction of the generated script code with
`Microsoft.Common.CurrentVersion.targets`, and whether this is needed
for all managed projects or just C# projects.
Also add a test covering the case that was broken.
Fixes: #22964
Issue: #21440
9c4d6404eb Tests/Environment: also test modifying ambient values
7d52d48a32 cmCTestRunTest: get the default value from the environment
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6682
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.
The minimum CMake version for Qt6 is 3.16, so all the calls to
cmake_minimum_required() are updated here to enforce that
minimum. This will avoid any CMake version-related warnings
from Qt.
Avoid hard-coding Qt5 where the tests could now be using
Qt5 or Qt6.
Fixes: #22188
Since commit 58d10cf6f1 (Alternative symlink-creating mode for
file(INSTALL ...), 2021-08-02) we test creating a symlink during
configuration to decide whether to activate some tests. Capture
the process output during the check to avoid leaking the error
message on failure.
The check added by commit 58d10cf6f1 (Alternative symlink-creating mode
for file(INSTALL ...), 2021-08-02) only works when re-running CMake in a
build tree after building `cmake`. Use the driving CMake to check
instead. Remove the stray link after creation.
Also remove the message on failure: we do not use that convention.
An new environment variable 'CMAKE_INSTALL_MODE' is introduced,
which can be used to ask CMake to create symbolic links
instead of copying files during a file(INSTALL ...).
The operation is at the file level only, directory trees are
still created using actual directories, not links.
Signed-off-by: Felix Lelchuk <felix.lelchuk@gmx.de>
Markus Ferrell