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
When preprocessing the rc file using the clang gnu front end we need to
force the source file type to a c file for the preprocessing to take
place.
Fixes: #21472
Customer reported problems detecting the Cray compiler on their Apollo80
system. We were checking for the __CRAYXC and __CRAYXE predefined
macros. These macros reflect the platform that the compiler is running
on, i.e. Cray XC and Cray XE machines. Naturally, this didn't work on
Apollo80.
This commit uses the official Cray compiler identification macros which
are defined on every platform:
CCE Version C Macro C++ Macro Fortran Macro
============ ======== ========= =============
version < 9 _CRAYC _CRAYC _CRAYFTN
version >= 9 __cray__ __cray__ _CRAYFTN
2c71d051fa Makefiles Generators: use compiler for dependencies generation
afd0f6785d Refactoring: Abstract Makefile line continuation format
b6068ce407 Refactoring: enhance include file filtering
3401403f69 Refactoring: Introduce place-holder for dependency target.
a97c41bf8b Refactoring: Makefiles Generators: Add support for various depends scanners
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Brad King <brad.king@kitware.com>
Merge-request: !5528
Brad King