The Intel Classic C++ compiler is based on EDG. It does not always
define `__cplusplus` correctly, but does define feature macros that we
can use to distinguish these modes.
The Intel Classic C++ compiler for Windows does not always define
`_MSVC_LANG` correctly, but does define feature macros that we can use
to distinguish these modes.
588371d2d5 Modules: Rename CMakeDetermine{CompileFeatures -> CompilerSupport}
4d27ef55bd Modules: Factor out helpers for GNU language standard flags
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !9366
In commit 5e700411d2 (FindMPI: add IntelLLVM MPI wrappers, 2024-01-19,
v3.29.0-rc1~92^2) we added `mpiicpx.bat` for C++ on Windows, but that is
a GNU-like front-end that we do not yet support. Use `mpiicx.bat` for
both C and C++ on Windows, just as we use `icx` to compile both.
Fixes: #25807
Rename the CMake script at
`${CMAKE_ROOT}\Modules\CMakeDetermineCompileFeatures.cmake` to
`${CMAKE_ROOT}\Modules\CMakeDetermineCompilerSupport.cmake`. Also,
rename the function defined in that script from
`cmake_determine_compile_features()` to
`cmake_determine_compiler_support()`.
Modify existing CMake scripts which were including the previous
CMake script to refer to the new file and call the new function.
Add the following macros to `${CMAKE_ROOT}\Modules\Compiler\GNU.cmake`:
* `__compiler_gnu_c_standards()`
* `__compiler_gnu_cxx_standards()`
These macros are used to define the
`CMAKE_<LANG><STANDARD>_STANDARD_COMPILE_OPTION` and
`CMAKE_<LANG><STANDARD>_EXTENSION_COMPILE_OPTION` variables for C-
and C++-based languages for GCC. The macros are similar to the
existing `__compiler_clang_cxx_standards()` macro found in
`${CMAKE_ROOT}\Modules\Compiler\Clang.cmake`.
Extend the fix from commit 1ab7c3cd28 (CheckSymbolExists: Work around
GCC failure with -pedantic-errors option, 2021-10-22, v3.23.0-rc1~498^2)
to apply to the per-config flags propagated by CMP0066's NEW behavior.
In commit 1ab7c3cd28 (CheckSymbolExists: Work around GCC failure with
-pedantic-errors option, 2021-10-22, v3.23.0-rc1~498^2) we used the same
code that was fixed by commit cec6f98018 (CMakeDetermineCompilerABI:
Avoid removing the flag after -Werror, 2023-05-29, v3.26.5~4^2).
Apply the fix to CheckSymbolExists too.
Extend the fixes from
* commit 079ea66468 (CMakeDetermineCompilerABI: Handle NVCC-style -Werror
flags, 2020-10-04, v3.19.0-rc1~45^2), and
* commit cec6f98018 (CMakeDetermineCompilerABI: Avoid removing the flag
after -Werror, 2023-05-29, v3.26.5~4^2)
to apply to the per-config flags propagated by CMP0066's NEW behavior.
5d33f41e23 ExternalProject: reword `LIST_SEPARATOR` to indicate what it *does*
611ffce98c ExternalProject: add an example of `LIST_SEPARATOR` usage
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9376
5d33f41e23 ExternalProject: reword `LIST_SEPARATOR` to indicate what it *does*
611ffce98c ExternalProject: add an example of `LIST_SEPARATOR` usage
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9376
Also remove the (IMO) confusing suggestion to have ` ` as a separator as
it interferes with things like spaces in argument values (e.g., paths)
or generated arguments such as `-GUnix Makefiles`. The new example is
likely more common usage of the facility.
Strawberry Perl may be in the `PATH` to provide `perl`, but it also
comes with a `pkg-config` tool that is unrelated to normal MinGW
distributions. Since commit c6efbd78d8 (MSVC: Teach find_library to
consider the 'libfoo.a' naming convention, 2024-01-19, v3.29.0-rc1~91^2)
we need to avoid searching Strawberry Perl's `.../c/lib` directory, so
do not let its `pkg-config` point us there.
Fixes: #25820
Issue: #23975
In commit 8218aed118 (IntelLLVM: support marking include paths as SYSTEM
directories, 2023-08-15, v3.29.0-rc1~81^2) this flag was added for the C
and C++ compilers, but was accidentally added for Fortran too. Remove
it for the latter, as it is unsupported.
Issue: #25807
Brad King