9c360b9eea FindMatlab: Fix search for MCR
bda5e2ac8f FindMatlab: Only include engine and dataarray libraries if they are found
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5600
b7f0327dcd Tests: Cover macOS host architecture selection on Apple Silicon hosts
5f882f6ce5 macOS: Offer control over host architecture on Apple Silicon hosts
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5589
Since commit b6c60f14b6 (macOS: Default to arm64 architecture on Apple
Silicon hosts, 2020-09-28, v3.19.0-rc1~63^2) we use `sysctl` to detect
that we are running on Apple Silicon in a way that pierces Rosetta.
This always sets `CMAKE_HOST_SYSTEM_PROCESSOR` to be `arm64` on such
hosts. However, macOS offers strong support for running processes under
an emulated `x86_64` architecture.
Teach CMake to select either `arm64` or `x86_64` as the host
architecture on Apple Silicon based on the architecture of its own
process. When CMake is built as a universal binary, macOS will select
whichever slice (architecture) is appropriate under the user's shell,
and `CMAKE_HOST_SYSTEM_PROCESSOR` will match.
Also offer a `CMAKE_APPLE_SILICON_PROCESSOR` variable and environment
variable to provide users with explicit control over the host
architecture selection regardless of CMake's own architecture.
Finally, if `CMAKE_OSX_ARCHITECTURES` is not set, pass explicit flags to
the toolchain to use selected host architecture instead of letting the
toolchain pick.
Fixes: #21554
7808cbd644 CMakeDetermineCompilerId: support Intel DPC++ compiler toolset for VS gen
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5579
Revert commit 887f3a88a6 (Intel: Add Intel DPC++ compiler
identification, 2020-09-21, v3.19.0-rc1~124^2). The compiler has
already been released, and is more usable with CMake by pretending to be
upstream Clang than by identifying it as a compiler for which we have
not implemented support.
Fixes: #21551
Revert commit 5c3a93ab88 (Intel: Add Intel Clang compiler
identification, 2020-09-29, v3.19.0-rc1~68^2). The compiler has already
been released, and is more usable with CMake by pretending to be
upstream Clang than by identifying it as a compiler for which we have
not implemented support.
Issue: #21551
Before Intel have only one compiler icl (Intel(R) C++ compiler) and
CMakeDetermineCompilerId has considered, that all toolchains with a word
"Intel" in the toolchain name is a icl compiler. But now Intel have also other
compiler - Intel(R) DPC++ compiler, which haven't working with cmake on
Visual Studio Generator because cmake try to use icl compiler, which cmake
can't found and because of this fails the configuration. This commit fix
this problem, and both compilers start to work correctly with
Visual Studio generator.
Fixes: #21546
Commit 951640f1f9 (FindPython: manage SOABI for all Python versions,
2020-08-11) extended support for Python2's SOABI variable in order to
support the PyPy interpreter as well. This caused a regression in the
way that the SOABI variable was built up for the CPython interpreter.
This caused the variable to be set to `.so` which ended up causing a
doubling of the resulting `SOABI` variable in the end.
Co-Author: Marc Chevrier <marc.chevrier@gmail.com>
Fixes: #21548
48aac247e9 Compile with explicit language flag when source LANGUAGE property is set
2e67a75acd Embarcadero: Simplify addition of -P flag for C++
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5522
f25ac39dee CMakeDetermineCompilerId: Tolerate stray text around INFO strings
5cb66f17ca CMakeDetermineCompilerId: Add whitespace to clarify logic
1ee99104f7 CMakeDetermineCompilerId: Filter IAR-AVR format INFO strings earlier
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5570
When cross-compiling with Xcode our compiler id test binary may be
compiled with multiple architectures. The INFO strings should be
identical and therefore de-duplicated. However, this can be broken by
stray text that happens to sit immediately before or after an INFO
string. Filter out such text so we can match clean INFO strings.
Fixes: #21526
bdfa5ac7f6 Merge branch 'master' into llvm-rc-preprocess-as-c
f7ff0d34f0 llvm-rc: Force C language for the clang gnu frontend
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5564
This change was originally made by commit 74b1c9fc8e (Explicitly specify
language flag when source LANGUAGE property is set, 2020-06-01,
v3.19.0-rc1~722^2), but it was reverted by commit 30aa715fac (Revert
"specify language flag when source LANGUAGE property is set",
2020-11-19) to restore compatibility with pre-3.19 behavior.
Implement the change again, but add policy CMP0119 to make this change
while preserving compatibility with existing projects.
Note that the `Compiler/{Clang,Intel,MSVC}-CXX` modules do not need to
specify `-TP` for their MSVC-like variants because we already use the
flag in `CMAKE_CXX_COMPILE_OBJECT`. Similarly for `Compiler/XL-CXX`
and `Platform/Windows-Embarcadero`.
Note also that this does not seem possible to implement for XL C.
Even with `-qsourcetype=c`, `xlc` complains about an unknown suffix:
`1501-218 (W) file /.../AltExtC.zzz contains an incorrect file suffix`.
It returns non-zero even with `-qsuppress=1501-218`.
Co-Author: Robert Maynard <robert.maynard@kitware.com>
Fixes: #14516, #20716
* Split large literal blocks into definitions lists.
* Add section headers.
* Add links to standard commands and variables.
* Use inline literals liberally.
* Enable code highlighting in literal blocks.
* Format command signatures according to modern conventions.
175beadd4c FindHDF5: support the hdf5hl_fortran-based variable names
adf108441e FindHDF5: improve error messages when a location variable isn't known
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5563
175beadd4c FindHDF5: support the hdf5hl_fortran-based variable names
adf108441e FindHDF5: improve error messages when a location variable isn't known
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5563
