The test project is compiled with a `-DVAR` compiler flag where `VAR` is
the result variable. Tell `try_compile` to add the flag through
`add_definitions` instead of `CMAKE_Fortran_FLAGS` so that it is not
used for linking. Otherwise some Fortran compilers (e.g. XL 15) do not
like the flag when used to drive linking.
The XL Fortran compiler's `-qmoddir=` flag sets the module output
directory but does not add the directory to the search path for using
modules. This is inconsistent with other compilers like the GNU Fortran
compiler's `-J` flag that does both. In order to make these consistent,
add the module output directory with a `-I` flag on the XL Fortran
compiler so that it will be searched when using modules too.
This fixes our `FortranModules` test's coverage of submodules on
Ninja + XL. That test places module files in a subdirectory that with
Ninja is not the current working directory when the compiler runs.
Fixes: #20400
Previously the `find_program` call we used to locate the test executable
but that can be broken by `CMAKE_FIND_ROOT_PATH_MODE_PROGRAM`. Instead
teach the test project to write a file with the location of the
executable it builds. Load that file to get the exact location.
Fixes: #20390
Newer versions of SWIG drop support for some target languages, and some
forks of SWIG (such as for Fortran and MATLAB) aren't supported by the
mainline version of SWIG.
Swig versions as old as 1.3.6 (circa 2001) and possibly older use the
same format for listing available wrappers "%-15s - Generate %s
wrappers", so component detection should be quite reliable.
Since commit 06d9e67fbd (FindPython: Add capability to specify directly
artifacts, 2019-08-15, v3.16.0-rc1~157^2) we accidentally add the result
variables `Python*_LIBRARY_RELEASE` and `Python*_LIBRARY_DEBUG` to the
cache. They are always computed from other results and so should not be
presented to users in cmake-gui and ccmake to edit.
Issue: #20362
Since commit 06d9e67fbd (FindPython: Add capability to specify directly
artifacts, 2019-08-15, v3.16.0-rc1~157^2) we accidentally expose cache
entries named `_Python...` to users in cmake-gui and ccmake. Mark those
entries as `INTERNAL` to hide them.
Issue: #20362
Prior to this, `gtest_discover_tests` could take multiple minutes if
many tests are present. This behavior was caused by a repeated addition
to the variable `script` in the `add_command` function using:
set(script "${script}${NAME}(${_args})\n" PARENT_SCOPE)
This takes very long for large variables.
This commit flushes the contents of the variable to ${CTEST_FILE} after
a certain size of the variable is reached.
In addition:
- cmake_minimum_required(VERSION ${CMAKE_VERSION}) is set to allow usage
of new policies. In particular, CMP0053 speeds up variable expansion.
- No longer appends strings using set(), but instead uses string(APPEND).
- An additional buffer for the tests variable is set.
In commit 46371132b3 (FindCUDA: CUDA_LIBRARIES doesn't contain raw
`-pthread`, 2019-11-11, v3.17.0-rc1~455^2) we introduced use of the
`Threads::Threads` target, but we do not `find_package(Threads)` on all
platforms. Use the target only if it exists.
Since commit d91b5a72cd (Ninja: Add support for CUDA nvcc response
files, 2019-05-30, v3.15.0-rc1~8^2) we use NVCC's `--options-file`
option to avoid long link command lines via a response file. However,
for non-device linking the host tools are used and the option does not
make sense. Update the logic to use `--options-file` only for device
linking. Linking with the host tools already has its own logic for
response files.
Fixes: #19954
Add an additional include flag to PCH usage command line to fix programs
that rely on `compile_commands.json` file. Pass it to the preprocessor
directly to avoid compiler driver to change it to '-include-pch'.
When preprocessor is requested to preprocess a file, it tries to get
the original filename from '.pch' and uses that file for preprocessing.
CMake generates a '.pch' file from the '.hxx' file by passing an empty
'.cxx' source file to the compiler as a compilation unit and the header
file with the '-include' flag. After that, compiler puts compilation
unit filename in the '.pch' as the original filename.
However, CMake build system uses empty file as the source file and
passes the header file using '-include-pch' flag. As a result, Clang
uses the wrong file for preprocessing and produces the corrupted
preprocessed file.
Fixes: #20355
Signed-off-by: Sergey Larin <cerg2010cerg2010@mail.ru>
One may encounter warnings if FindPkgConfig is used in any project, even
indirectly, that has set any of these policies to old explicitely or requires
an older version.
* Insert section and subsection headers (because this is a very long
doc page)
* In the Introduction, first say that module is included automatically
* Then start with operational definition of components
* Remove duplications
* Also reword the description of the command cpack_add_component
* In summary:
* we configure generators, not the generated installers
* we generate installers or source packages, not source package installers
* In Introduction:
* Make paragraph on binary installers more concise
* Remove example that refered to CMake source tree
* Add paragraph on source packages
* omit the parenthesis on graphical installers
