Add `COMPILE_WARNING_AS_ERROR` target property and supporting
`CMAKE_COMPILE_WARNING_AS_ERROR` variable.
`COMPILE_WARNING_AS_ERROR` is initialized by
`CMAKE_COMPILE_WARNING_AS_ERROR`. It is a boolean variable. If it is
true, it expands to a different flag depending on the compiler such that
any warnings at compile will be treated as errors.
Supports compiler ids that I could find a relevant flag for.
The change in commit cc4da8d13a (IAR/CXX: Fix compatibility with CMP0057
OLD, 2022-01-29, v3.23.0-rc1~46^2) broke the detection of C++ version
because the `IN_LIST` operator cannot work directly on a list but
requires a variable.
To be more consistent between genex and variables as well as
the forecomming LINK_GROUP genex, rename variable *_LINK_USING_<FEATURE>*
in *_LINK_LIBRARY_USING_<FEATURE>*
Commit a9073db7 (IAR: update language specification detection, 2021-09-23)
added usage of the if() IN_LIST operation and forgot to account for it not
being available in CMP0057 OLD mode.
Push and temporarily enable the policy. Also avoid the unnecessary temporary
variable for the list.
Fixes#23147.
Since commit f29e1874ad (Compiler/MSVC: use the `-external:I` flag for
system includes, 2020-05-19, v3.22.0-rc1~593^2) we use the new flag
followed by the include directory as a separate argument. Some versions
of `clang-cl` and `clang-tidy` do not support the flag unless the
include directory is attached to it, so use that form instead.
Fixes: #22979
Add link flags during the "device compile" step.
Enabled the relevant tests. The disable reasons regarding separable compilation
were outdated and the actual failure case was device link flags support.
c5cc4ddac4 MSVC: Add support for C17
6561b032bc MSVC: Tolerate c_std_17 and c_std_23 features on older compiler versions
22f804e0ec MSVC: Refactor C compile features table for C90, C99, and C11
Acked-by: Kitware Robot <kwrobot@kitware.com>
Reviewed-by: Raul Tambre <raul@tambre.ee>
Merge-request: !6677
MSVC `cl` versions prior to 19.27 had no `-std:c*` flags for C
standards. List the `c_std_{17,23}` features anyway. This allows
projects to at least attempt compilation with these compilers since they
do not have any modes.
The custom "no modes" `cmake_record_c_compile_features` implementation
should only be used in `cl` versions prior to 19.27 because they had no
`-std:c*` flags for C standards. For 19.27 we need a different custom
implementation to account for partial C11 support. For 19.28 and above
we can use the default implementation through the `*__HAS_FULL_SUPPORT`
settings.
We already use this pattern in the MSVC C++ compile feature table.
Due to MCST LCC compiler identification is now changed to LCC,
there should be a way for old projects to still identify it as GNU,
as it was before.
This commits adds the policy:
CMP0129: Compiler id for MCST LCC compilers is now LCC, not GNU.
This policy controls such a behavior.
OLD behaivior is to treat LCC as GNU, NEW is to treat is as LCC.
The target properties `CUDA_SEPARABLE_COMPILATION` and `CUDA_PTX_COMPILATION`
now aren't mutually exclusive and can now be used together on the same
target.
02b2607a5c Help: Add release note for MCST LCC compiler support
e5d9fce03f LCC: Add dedicated support for MCST LCC compiler
2b9ef77944 CPack/DEB: deal with broken dpkg-shlibdeps on E2K architecture
0995c75301 Tests/RPM: skip tests tat rely on debugedit if it's not found
ea55ac9a51 Tests/RunCMake/CommandLine: Deal with locales that are different from English
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6608
Divert LCC compiler as a new one, instead of treating it as GNU.
Since old times, Elbrus C/C++/Fortran Compiler (LCC) by MCST has been
passing checks for GNU compilers, so it has been identified as GNU.
Now, with intent of seriously upstreaming its support, it has been
added as a separate LCC compiler, and its version displays not a
supported GCC version, but LCC version itself (e.g. LCC 1.25.19 instead
of GNU 7.3.0).
This commit adds its support for detection, and also converts basically
every check like 'is this compiler GNU?' to 'is this compiler GNU or
LCC?'. The only places where this check is untouched, is where it
regards other platforms where LCC is unavailable (primarily non-Linux),
and where it REALLY differs from GNU compiler.
Note: this transition may break software that are already ported to
Elbrus, but hardly relies that LCC will be detected as GNU; still such
software is not known.
In commit 3aaf1d91bf (MSVC: C++20 final flag, C++23 support, 2021-05-29,
v3.20.4~7^2~1) we forgot to add `cxx_std_23` to the fallback table for
MSVC versions from VS 2010 through VS 2015. This allows project to at
least attempt compilation with these compilers since they do not have
any modes.
Issue: #22729
The changes are part of CMP0128.
When the standard level is unset:
* Flags are added if extension mode doesn't match the compiler's default.
Previously logic only worked if LANG_EXTENSIONS was ON. Fixes#22224.
* The full flag is used. Previously CMAKE_LANG_EXTENSION_COMPILE_OPTION was
used. This was only supported for IAR.
Otherwise:
* Avoid adding flags if not necessary per the detected compiler defaults.
* Fixed check for when the requested standard is older. It now matches the
nearby comments.
I reworded the fallback comment as its logic was a bit difficult to wrap my
head around.
There was a mismatch in the executable suffix between the compiler
detection and try_compile. This resulted in the generated executable
having a different suffix than what try_compile was looking for.
The IAR module is changed to use the same suffix as try_compile.
Fixes: #22567
It only makes sense to use the CMake package from the same ROCm
installation that the compiler uses. Ask the HIP compiler to report the
location of the ROCm installation. Verify up front that it contains the
expected CMake package file.
