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`.
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
Each source compilation generates a dependencies file. These dependencies
files are consolidated in one file per target. This consolidation is done
as part of command 'cmake -E cmake_depends` launched before evaluation of
makefile dependency graph.
The consolidation uses the same approach as `CMake` dependencies management.
Fixes: #21321
Revert commit 74b1c9fc8e (Explicitly specify language flag when source
LANGUAGE property is set, 2020-06-01, v3.19.0-rc1~722^2) and the lookup
tables from its two immediate ancestors. The purpose of that change was
to convert an explicit `LANGUAGE` source file property into an explicit
language specification compiler flag like `-x c`. This seems reasonable
since the property is documented as meaning "indicate what programming
language the source file is". It is also needed to help compilers deal
with non-standard source file extensions they don't recognize.
However, some projects have been setting `LANGUAGE C` on `.S` assembler
source files to mean "use the C compiler". Passing `-x c` for them
breaks the build because the `.S` sources are not written in C. These
projects should be updated to use `enable_language(ASM)`, for which
CMake often chooses the C compiler as the assembler when using
toolchains that support it (which would have to be the case for projects
using the approach).
Revert the change for now to preserve the old behavior for such projects.
We can re-introduce it with a policy in a future version of CMake.
Fixes: #21469
Issue: #14516, #20716
Use the infrastructure added by commit 646fb1a646 (CompileFeatures:
memoize C++ compilers with full language level support, 2019-03-27) to
avoid using a `try_compile` to check for C++14 feature support when the
running compiler is known to have all features.
Use the infrastructure added by commit 646fb1a646 (CompileFeatures:
memoize C++ compilers with full language level support, 2019-03-27) to
avoid using a `try_compile` to check for C++11 feature support when the
running compiler is known to have all features.
Use the infrastructure added by commit 646fb1a646 (CompileFeatures:
memoize C++ compilers with full language level support, 2019-03-27) to
avoid using a `try_compile` to check for C++98 feature support when the
running compiler is known to have all features.
Condition all calls to `_record_compiler_features_{c,cxx}` on
`_result EQUAL 0` so that adding new language standards later does
not need to update them. Avoid some duplicate compiler version
checks by conditioning C11 and CXX14 feature recording on the
existence of `CMAKE_{C11,CXX14}_STANDARD_COMPILE_OPTION` (whose
setting already used the version check).
Prior to commit v3.4.0-rc1~71^2 (Project: Determine default language
dialect for the compiler, 2015-09-15) we always guessed the default
language standard dialect based on the compiler version. This was not
reliable so that commit switched to computing the default language
standard dialect while detecting the compiler id.
When a toolchain file uses CMakeForceCompiler to set the compiler id
then the detection does not occur. Therefore commit v3.4.0-rc1~54^2
(Project: Don't require computed default dialect if compiler was forced,
2015-09-22) made the lack of detection an error only if the compiler was
not forced. However, this means that projects using CMakeForceCompiler
no longer even get the guess that we had before so <LANG>_COMPILER does
not work.
Due to the sophistication of CMake's compiler detection logic projects
should be ported away from using CMakeForceCompiler. In the meantime,
restore a guess of the default language standard dialect when the
compiler is forced.
Commit 7235334a (Project: Determine default language dialect for the
compiler., 2015-09-15) introduced a mechanism to determine the default
dialect used for the running compiler. If conditions in
the <CompilerId>-<Lang>.cmake file are such that compile features for
that version of the compiler should be supported, the _DEFAULT_STANDARD
is set to the computed value.
However, the CMakeForceCompiler module allows users to bypass execution of the
compiler by CMake. In that case, do not set the _DEFAULT_STANDARD variable at
all, which effectively disables the compile-features where the module is used.
No compile features have ever been recorded where the module is used so no
functionality is lost.
If no compiler feature information is known for a given compiler
version, do not set a language standard default either. The two
settings must be recorded consistently.
GNU-CXX already has complex logic and sets the _result to 0 before
tests which may set it to something else.
Change the other modules to be consistent with that.
Use the highest standard compile flags available if requested language
version is too new.
This supports use-cases like
set(CMAKE_CXX_STANDARD 14)
# Compiled with -std=c++11 with GNU 4.7, which has no -std=c++14
# or equivalent flag
add_executable(main main.cpp)
This can be used in combination with preprocessor defines which
communicate the availability of certain language features for
optional use.
Record the availability of this feature for GNU 4.8 on (UNIX AND
NOT APPLE) only. In the future, availability can be recorded for
earlier GNU, for other platforms and for other compilers. Initially
the affected configurations are as restricted as possible to allow
for easy testing while extending the features vector in only one
dimension.
The error message when using the set_property API directly is not
very good, but follow up commits will provide origin debugging of
the property and a target_compile_features command which will
provide a configure-time backtrace when possible.
This corresponds to the g++ and clang++
option -fvisibility-inlines-hidden on linux. On Windows with MinGW,
this corresponds to -fno-keep-inline-dllexport. That option is
not supported by clang currently.
This moves GNU compiler flags into new-style modules
Compiler/GNU-<lang>.cmake
Platform/<os>-GNU-<lang>.cmake
We use language-independent helper modules
Compiler/GNU.cmake
Platform/<os>-GNU.cmake
to define macros consolidating the information.
This teaches CMake to detect implicit link information for C, C++, and
Fortran compilers. We detect the implicit linker search directories and
implicit linker options for UNIX-like environments using verbose output
from compiler front-ends. We store results in new variables called
CMAKE_<LANG>_IMPLICIT_LINK_LIBRARIES
CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES
The implicit libraries can contain linker flags as well as library
names.
