Previously we saved it in the cache, which:
* Persists even if a new version of CMake changes how the check works.
* Does not propagate to `try_compile` checks.
Extract the effective linker during the computation of implicit artifacts
delivered by the compiler to the linker.
Define various variables describing the linker:
* CMAKE_<LANG>_COMPILER_LINKER
* CMAKE_<LANG>_COMPILER_LINKER_VERSION
* CMAKE_<LANG>_COMPILER_LINKER_ID
* CMAKE_<LANG>_COMPILER_LINKER_FRONTEND_VARIANT
This is complementary to feature introduced by commit 96a953b1ed
(Add options to specify linker tool, 2023-09-27).
Fixes: #17596, #18209, #25344
Offer the capability, through variable `CMAKE_LINKER_TYPE`, as well as
the target property `LINKER_TYPE` to specify which linker must be used.
The implementation of this capability is specified by variables specific
to the language and linker type: `CMAKE_<LANG>_USING_LINKER_<TYPE>`.
Some definitions are provided as part of `CMake`.
For example, to select the `LLVM` linker rather than the standard one,
the type `LLD` should be specified through the variable `CMAKE_LINKER_TYPE`.
And, on `Apple`, `Linux` and some environments on `Windows`, the variable
`CMAKE_<LANG>_USING_LINKER_LLD` has value `-fuse-ld=lld`. And for `Windows`
environments based on `MSVC`, where the linker is used directly, the tool
`lld-link.exe` will be used rather than `link.exe`.
Fixes: #19174, #24254, #24990
For example, with GNU `as`, we match `GNU assembler`, but with GNU `gcc`
as the assembler, we do not match anything. Distinguishing these cases
may be useful for constructing assembler command lines.
CMake commands vs_link_dll and vs_link_exe, performing linking on MSVC,
are responsible for calling resource compiler and manifest tool.
Before this commit, both of these tools were called directly, with the
expectation that they are available in the `PATH`. This has been fixed
by respecting CMake variables `CMAKE_RC_COMPILER` and `CMAKE_MT`
defining paths to these tools.
Fixes: #17804
Compilers such as MSVC and IAR may have variants that target different
architectures. We have been using a `MSVC_<LANG>_ARCHITECTURE_ID`
variable to hold this information for MSVC. Add an alternative with a
more general name (later we can port MSVC to it too).
This additional information may be needed to generate proper invocations
of the compiler based on its architecture variant.
The variables recently added by commit b9d36826 (Add 'CMAKE_GCC_AR' and
'CMAKE_GCC_RANLIB' variables, 2017-03-08) are more appropriately managed
with language-specific names rather than toolchain-specific names.
This commit changes the way how the assembler support works in cmake.
The language "ASM" now always uses the C/Cxx compiler instead
of the assembler directly. This fixes#8392, assembler files are
not preprocessed.
If one wants to use the assembler directly, the specific
assembler "dialect" has to be enabled. I.e. to get as/gas,
you have to use now ASM-ATT, the same way for ASM_MASM and ASM_NASM.
Implemented this now for gcc.
SunStudio, IBM, HP and Intel still todo.
Alex
two-step priority (None or Prefered)
Current order: ASM 0, C 10, Fortran 20, CXX 30, Java 40
This is the same order as automake choses:
http://www.gnu.org/software/automake/manual/html_node/How-the-Linker-is-Chosen.html
This change should be backward compatible:
if there is a project using fortran and CXX, they had to set the
LINKER_LANGUAGE explicitely, otherwise cmake complained (but still generated
the project files). Explicitely setting the linker language still overrides
automatic detection.
If somebody has a custom language for cmake and the PREFERENCE starts with
"P", its changed to 100, which gives it preference over all other languages
(except the other custom languages which have also "Prefered"). "None" is
converted to 0.
Alex
