The presence of the `1041` seems to solely depend on whether a given
Intel compiler release was available in Japanese or not. Install it if
it is present and silently ignore it otherwise.
Example: The Intel 2018.0 release did not ship it, but the 2018.1
compilers have it.
40434631 Autogen: Use integers instead of strings for the Qt version
be11a852 Autogen: Use project relative paths in rcc custom command comment
ab9d5896 Autogen: Detect rcc feature once during configuration
2a85b5ac Autogen: Make cmQtAutoGeneratorInitializer an instantiable class
75819b86 Autogen: Add and use cmQtAutoGenerator base class
27ed3b35 Autogen: Rename cmQtAutoGenerators to cmQtAutoGeneratorMocUic
1cd285fe Autogen: Remove rcc code from cmQtAutoGenerators
a87f82e0 Autogen: Switch to use custom commands for RCC
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1494
The port maintainers on FreeBSD normalize the library names to not
include the bit and HDRI options.
Furthermore, `--quantum-depth=32` and `--quantum-depth=64` will yield
`Q32` and `Q64` suffixes in the library names.
Issue: #17492
We used to detect the `rcc` features before every `rcc` list invocation
wich resulted in `rcc` be called twice for every listing operation.
Now we detect the `rcc` list capabilities once during configuration and
pass it to the cmake_autorcc target in the info file.
Instead of processing all `rcc` invocation requests in the
_autogen target that calls `cmake -E cmake_autogen ...` once,
use a dedicated custom command that calls
`cmake -E cmake_autorcc ...` for each `.qrc` file.
This allows parallel `.qrc` file processing and reduces the
workload (and complexity) in the _autogen target.
If only `AUTORCC` is enabled, the _autogen target won't be created
at all since it is now used for `AUTOMOC` and `AUTOUIC` only.
For `.qrc` files that are GENERATED a custom target is used
instead of a custom command.
Closes#17161
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
