Through hint Python_FIND_IMPLEMENTATIONS it is possble to specify, as an
ordered list, which implementations must be searched for.
Currently possible values are:
* CPython
* IronPython
This is an old module from when VTK and other Kitware projects drove the
addition of commands and modules into CMake itself. Modern VTK doesn't
need this module and it can be ignored.
This module is kept around so that the ancient VTK versions which use it
are not broken by it. VTK itself stopped using the module in 2012 and
the last usage by an example in VTK was removed in 2020.
Fixes: #20591
c77c92791c FindSquish: Fix setting the application under test
879b279154 FindSquish: Fix launching the Squish server process on Windows
0bc4fa2be2 FindSquish: Fix finding on Windows
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4620
On Windows, toolchains like MSVC require a set of environment variables
to be configured for the compiler to work correctly. The scripts that
prepare these environments typically put the compiler's directory ahead
of others in the `PATH`. Teach the Ninja generators to use this as a
heuristic to select the compiler when none is explicitly specified.
This is not necessary with Makefile generators because each toolchain's
environment comes with its own make tool variant, and the corresponding
Makefile generator (e.g. "NMake Makefiles") automatically implies the
matching compiler.
Fixes: #20585
65c1320719 Compiler/TI: Fix C++ toolchain command-lines
4110d9dffb Compiler/TI: Fix linker command line for C++
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4627
There are countless posts (e.g. stack overflow) that start /b takes a window title as first argument.
Once I added a random string there the server was started and things started to work.
When looking at `list(FIND)` result, zero index is ignored due to
incorrect error handling, and users can't set dependencies on mkdir
step.
Fixes: #20605
Run `Utilities/Scripts/BoostScanDeps.cmake` with the Boost 1.73.0
sources to compute dependencies.
This includes a new Boost.Nowide library.
Special case: Boost.Filesystem is an optional dependency as the include
is only required to make Boost.Filesystem use UTF-8 paths on user
request
properties LINK_OPTIONS and INTERFACE_LINK_OPTIONS are propagated
to the device link step.
To control which options are selected for normal link and device link steps,
the $<DEVICE_LINK> and $<HOST_LINK> generator expressions can be used.
Fixes: #18265
The whole script looks rather dated and dusty, but it actually does find
newer Squish versions - e.g. version 6.5 here.
I assume more work is needed, but at least with this tiny patch the path
is located on Windws when the SQUISH_INSTALL_DIR environment variable is
set.
Instead of relying on SDKSettings.plist which does not contain the
certain architectures, deduce the supported architectures by
inspecting libSystem.tbd and libSystem.dylib.
.tbd files are text files, so just parse out the archs string.
.dylib files can be fat or non-fat, so use lipo -info to extract
the architectures and parse lipo output.
Fixes: #20588
Simplifies CUDA target architecture handling.
Required for Clang support as Clang doesn't automatically select a supported architecture.
We detect a supported architecture during compiler identification and set CMAKE_CUDA_ARCHITECTURES to it.
Introduces CMP0104 for backwards compatibility with manually setting code generation flags with NVCC.
Implements #17963.
d86fcc6359 CUDAToolkit: Deduce toolkit binary directory from compiler path only for NVCC
87e98bf8be CUDA: Forward CMAKE_CUDA_COMPILER_TARGET in try_compile()
60e60b9201 GNU: Disable depfiles in try-compile mode only for GCC
5f02add366 CUDA: Refactor PTX compilation flag into compiler modules
25439c7d62 Clang: Refactor CXX standard flags into __compiler_clang_cxx_standards()
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4567
Add the `VERBATIM` option to our `add_custom_command` calls so that all
arguments are correctly escaped for the shell. Otherwise when using a
POSIX shell on Windows, the `-classpath` separator is `;` and without
quoting ends the command.
Fixes: #20567
Inspired-by: Nevyn Bengtsson <nevyn.jpg@gmail.com>
Skipped tests are currently reported as successful. Using
SKIP_REGULAR_EXPRESSION on googletest's output prefix, skipped tests can
be detected and accounted accordingly.
Using SKIP_RETURN_CODE is not possible, googletests exit code is not
affected by skipped tests.
Fixes: #19669
The `QUIET` mode suppresses any mention of our logged output, so do not
bother logging it. This also provides a way for users to avoid saving
possibly large output on disk.
Fixes: #20554
The output of gcov can be large and we only display it in a failure
case. Put it in a log file to avoid accumulating large output in
memory.
Issue: #20554
Use `<arch>-SDK-NOTFOUND` instead of an empty string as a placeholder in
`CMAKE_APPLE_ARCH_SYSROOTS` for architectures whose SDK is not found.
This ensures the length of `CMAKE_APPLE_ARCH_SYSROOTS` matches the
length of `CMAKE_OSX_ARCHITECTURES`. It also makes the missing SDKs
more visible in the value.
Issue: #20534
These standard flags are the same for CXX, OBJCXX and CUDA.
Refactor them into a single macro to reduce duplication and so we can easily reuse them.
Updated bootstrap script to search in the general Clang module instead of the language-specific.
Since commit 1c2d031cbd (Add -E cmake_llvm_rc to preprocess files for
llvm-rc, 2020-01-14, v3.17.0-rc1~24^2) with llvm-rc we explicitly
preprocess RC source files and then compile separately without -I flags.
This broke cases where the RC source references data files adjacent to
itself or in the include path.
This change adds the expansion of the include paths when calling the
llvm-rc in order for the resource files to be picked up correctly by
llvm-rc. Since the RC compiled file is first preprocessed, the file
being compiled by llvm-rc resides in the build directory. In order for
llvm-rc to find the resource data specified relative to the .rc file
being compiled, the source file path is preppended in the include list
so that the original source path takes priority over all the other
includes paths specified.
A space was added in the CMAKE_INCLUDE_FLAG_RC to make the include
directive work properly for llvm-rc. Checks on the rc.exe showed that
the syntax change doesn't affect it's proper operation.
Fixes: #20529
If java_class_filelist exists, remove previous class files before building the
new ones. If java_sources content has changed, clean and rebuild the class
files of the target.
Fixes: #20377
46d9006efa XL: Add comment clarifying why we pretend it has full C++11/14 support
4aaa9ea96c XL: C++14 language level flags are only available on Linux
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4551
46d9006efa XL: Add comment clarifying why we pretend it has full C++11/14 support
4aaa9ea96c XL: C++14 language level flags are only available on Linux
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4551
Since commit b0f46c48f6 (CompileFeatures: Now able to presume full
language level support, 2019-03-06, v3.15.0-rc1~265^2~1) we pretend that
the XL compiler has full C++11 and C++14 support so that projects
specifying granular features will at least get the corresponding
compiler mode. This is a work around for our lack of a full feature
check table for this compiler that works in common cases. Add a comment
explaining this.
Issue: #20521
Since commit 458ea9d76c (XL: Add C++14 language level flags, 2019-04-15,
v3.15.0-rc1~226^2) we use `-qlanglvl=extended1y` for C++14 with XL 16.1.
However, that flag is only supported on a Linux host.
Issue: #20521
On platforms where our default Boost static library prefix is incorrect,
make it possible for users to set it explicitly to work around the problem
until FindBoost can be updated.
Fixes: #20372
2c724c3aea llvm-rc: Write depfile to location specified by the generator
4cc876540e llvm-rc: Select preprocessor from active languages
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4524
2c724c3aea llvm-rc: Write depfile to location specified by the generator
4cc876540e llvm-rc: Select preprocessor from active languages
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4524
Prior to commit 3c125c6de0 (VS: Support Visual Studio Clang Toolkit
identification, 2019-12-03, v3.17.0-rc1~341^2) using `-T ClangCL`
would work but `CMAKE_{C,CXX}_COMPILER` would be detected as `cl.exe`
even though `clang-cl.exe` is the actual compiler. That commit
attempted to fix the detection by using `$(ClangClExecutable)`
as we do for LLVM-distributed toolsets, but that is not actually
defined. Instead, look for `$(CLToolExe)` in the `PATH`.
Fixes: #20504
Move the depfile flags to `CMAKE_DEPFILE_FLAGS_RC` so that they
are only usedwith generators that use depfiles. Also switch to
using the `<DEPFILE>` placeholder for the location of the depfile
so that it goes where the generator expects.
Fixes: #20493
The llvm-rc preprocessor is selected according to the
CMAKE_C_COMPILER_ID / CMAKE_CXX_COMPILER_ID which are only defined when
the C or CXX language is active.
905d5667e8 FindRuby: Add support for RVM installations
e6699b9b59 FindRuby: Validate Ruby_EXECUTABLE before accepting it
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4386
Since commit 957c2aac7f (RC: Simplify selection of resource compiler
based on C/C++ toolchain, 2015-05-07, v3.3.0-rc1~93^2~5) we select
windres as the RC compiler on MinGW via `CMAKE_RC_COMPILER_INIT`. Drop
the special case from commit be9afbf453 (Find mingw's windres also when
Unix Makefiles are used, 2012-08-27, v2.8.10~152^2).
Introducing a new DISCOVERY_MODE mode option, which provides greater control
over when gtest_discover_tests perforsm test discovery.
It has two supported modes:
* POST_BUILD
* PRE_TEST
POST_BUILD is the default behavior, which adds a POST_BUILD command
to perform test discovery after the test has been built.
PRE_TEST is a new mode, which delays test discovery until test execution.
DISCOVERY_MODE can be controlled in two ways:
1. Setting the DISCOVERY_MODE when calling gtest_discover_tests
2. Setting the global CMAKE_GTEST_DISCOVER_TESTS_DISCOVERY_MODE
prior to calling gtest_discover_tests
By delaying test discovery until ctest runtime,
we can provide better cross compile support,
because we're more likely to be in an environment that can run the test executable.
This was achieved by moving the command for test discovery
into the generated ctest include file.
In PRE_TEST mode, the generated include file now has the form:
if(EXISTS "path/to/test.exe")
if("path/to/test.exe" IS_NEWER_THAN "path/to/ctest_file")
// command to discover tests
// and generate ctest_file
endif()
include("path/to/ctest_file")
endif()
elseif()
// test not built
endif()
Which generates the appropriate CTest files at runtime
and regenerates the CTest files when the executable is updated.
In the old approach, test discovery was always added as POST_BUILD step
and the executable was ran in order to scan for tests.
If the test executable failed to run for any reason,
this resulted in a link failure.
This failure could more commonly occur when cross compiling,
because your build environment might not have
the appropriate runtime environment dlls required to run the test executable.
I also ran into the issue when compiling a Qt application using Qt Creator.
Qt Creator manages its build and runtime environments separately
and only adds the Qt dlls to the environment during runtime -- not during build.
So when gtest_discover_tests ran my test executable,
it promptly crashed because the environment wasn't correct,
which resulted in a build failure.
Setting the DISCOVERY_MODE to PRE_TEST fixed my build failure
by delaying test discovery until runtime,
because this allowed the test exe to run in the proper environment.
A few non-trivial implementation details worth noting:
1. bracket_arguments
In the PRE_TEST side, parameters whose contents might contain special characters,
need to be handled with great care.
To aid in escaping these list arguments, backslashes, and other special characters,
and ensuring that they are preserved in the generated file,
bracket arguments (i.e. [== <...> ==]) are used.
For example:
gtest_discover_tests(
...
EXTRA_ARGS how now "\"brown\" cow"
)
Generates a file with the following call:
gtest_discover_tests_impl(
...
TEST_EXTRA_ARGS [==[how;now;"brown" cow]==]
)
This way the arguments are forwarded correctly.
2. multi-config generators
Multi-Config generators (e.g. MSBuild) now work more correctly in
PRE_TEST than POST_BUILD.
PRE_TEST is more correct because it will generate a unique CTest file for each configuration.
It generates a per config file responsible for test discovery:
foo[1]_include-Debug.cmake
foo[1]_include-MinSizeRel.cmake
foo[1]_include-Release.cmake
foo[1]_include-RelWithDebInfo.cmake
A per config file for containing the google tests:
foo[1]_tests-Debug.cmake
And an outer ctest file:
foo[1]_include-Debug.cmake
That is generically written to include the correct configuration file
by looking at the value of ${CTEST_CONFIGURATION_TYPE} when CTest runs.
POST_BUILD, in contrast, preserves the existing functionality.
Tests are disocvered based on the last configuration that was chosen
and only a single file is produced:
foo[1]_include.cmake
foo[1]_tests.cmake
But it runs with whatever executable requested by ctest --config,
which means it's possible to run the wrong tests
if some tests were enabled in one configuration but not another.
