cd2cdfe2 FindRuby: Add support for versions 2.2, 2.3, and 2.4
23ab451a FindRuby: Fix match of '.' in version numbers
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1493
When using a real MSVC compiler for `C` or `CXX`, use the version of
that compiler for `MSVC_VERSION`. This is preferred over the MSVC
version that a non-MSVC compiler "simulates".
Fixes: #17468
Since commit v3.10.0-rc5~3^2 (FindOpenGL: Default to non-GLVND libraries
for legacy GL, 2017-11-08) users may set `OPENGL_gl_LIBRARY` to empty to
use GLVND components for the legacy GL interfaces. This is useful only
when one knows in advance that the GLVND components will be found.
Add a `OpenGL_GL_PREFERENCE` variable to specify a preference for legacy
GL or GLVND. The latter can suppress `OPENGL_gl_LIBRARY` only when the
needed GLVND components are found. If no preference is explicitly
specified, choose a default based on whether GLVND components were
requested (because this indicates the project has been updated for
CMake 3.10).
Issue: #17437
Issue: #17449
If the value of `CMAKE_HOST_SYSTEM_PROCESSOR` also happens to be set as
a variable by a project (e.g. `AMD64`), allowing `if()` to
auto-dereference is unlikely to produce a value that matches "64".
Instead let `if()` auto-dereference `CMAKE_HOST_SYSTEM_PROCESSOR`.
Fixes: #17460
If the compiler given in I_MPI_... could not be found, the Intel MPI
wrappers emit an error like "line 590: ifort: command not found".
The script should currently fail to match the output of this for
information, but we should generally treat such an output as invalid,
since the displayed configuration line can become a mixup between Intel
and GNU compiler settings.
OpenMP libraries must always be found in the implicit linking
directories of a compiler when using the OpenMP compile flag. If a suitable OpenMP library is also found in for example some CMAKE_PREFIX_PATH, this can lead to the module finding the incorrect library.
On the other hand, CMAKE_PREFIX_PATH can't ever be a location that we
need to consider since the OpenMP compile flag would not work if we
needed to.
`DOXYGEN_DOT_FOUND` is only set if `_Doxygen_keep_backward_compat` is
used (when no components are requested), so use `Doxygen_dot_FOUND`
directly. Preserve the "YES" or "NO" value used previously.
Projects using `OPENGL_LIBRARIES` or `OpenGL::GL` expect legacy GL.
Although GLVND OpenGL+GLX provides legacy GL interfaces, using those
library files may conflict with legacy GL library files used by
dependencies (or dependents) of such projects. Therefore we should
not yet use OpenGL+GLX when a legacy GL library is available.
If `OPENGL_gl_LIBRARY` is set then use it as the legacy GL library.
If it is *not* set then fall back to using GLVND OpenGL+GLX to provide
legacy GL interfaces. This will allow users to build projects using
GLVND even if they have not been ported.
Fixes: #17437
Introduces CPACK_DEFAULT_DIRECTORY_INSTALL_PERMISSIONS
variable which adds support for functionality introduced
by CMAKE_DEFAULT_DIRECTORY_INSTALL_PERMISSIONS variable.
Fixes#17333
# Conflicts:
# Help/release/dev/cmake-default-dir-install-permissions.rst
Fix a typo from commit v3.6.0-rc1~85^2 (HDF5: Refactor the use of
compiler wrappers, 2016-04-04) that accidentally used the HDF5 C++
version (which could be empty) while detecting the C patch version.
The detection failed for patch releases, such as `1.10.0-patch1`
becoming `.1` instead of `1.10.0.1`.
Commit v3.8.0-rc1~123^2 (UseSWIG: Automatically scan dependencies of SWIG files
for Makefiles, 2016-12-21) introduced automatic dependency scanning for files
`%include`d in a swig interface definition file. This works fine as long as no
such file is removed. But removing a dependent file breaks an incremental build
and `make` complains about a missing dependency, see #16830.
Integrate the approach proposed in the issue above into the SWIG-module, do the
workaround in a conditional step as it arises only for Makefile generators. For
other generators use the implementation before that commit.
Fixes: #17433.
3c368228 Flang: Add support for compiling sources on Windows
72d27964 Flang: Identify as simulating MSVC on Windows
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1430
Since commit v3.9.0-rc1~148^2 (Do not assume GCC libs are linked by all
compilers, 2017-05-05) we no longer filter out all `gcc*` implicit link
libraries. This allows mixing of gcc and non-gcc compilers across
languages. However, this caused a subtle problem with how GCC makes
exception handling symbols available to linked binaries.
GCC (at least on MinGW) provides two different libraries with exception
handling symbols:
* gcc_s: A shared library with -fvisibility=default, used by -shared-libgcc.
* gcc_eh: A static library with -fvisibility=hidden, used by -static-libgcc.
The C compiler (on MinGW) defaults to -static-libgcc and uses gcc_eh.
The C++ compiler defaults to -shared-libgcc and uses gcc_s when linking
shared libraries and executables so that exceptions can propagate across
shared libraries [1]. When linking a mixed-language binary, the C++
compiler should be used along with its choice of gcc_s. In this case
gcc_eh should not be added even though the C compiler implies it because
gcc_s supersedes it.
Since the above-mentioned change, CMake is adding gcc_eh to C++ link
lines that also contain C code on MinGW. This causes both gcc_s and
gcc_eh to be used, which is incorrect. We can fix this simply by
excluding gcc_eh from the C compiler's implicit link libraries.
[1] https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Link-Options.html#Link-OptionsFixes: #17436
When we run `csc.exe /help` we look for "Version" in the output.
Explicitly ask for the output in English.
Reported-by: guttally@users.noreply.github.com
d70bdc72 FindBoost: support more than one number in version components
335816ef FindBoost: use CMake's compiler version rather than querying again
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1441
