LLVMFlang 18.0 adds MSVC runtime library selection flags and associated
Fortran runtime library variants. Resolve the corresponding FIXME left
by commit 26bf32cdc6 (LLVMFlang: Add support for targeting MSVC ABI on
Windows, 2023-09-28, v3.28.0-rc1~10^2).
Issue: #24840
The compiler does not yet support everything needed to integrate well
with the MSVC ABI, in particular for runtime library selection and debug
format selection. Document them in FIXME comments and leave this
support undocumented by CMake for now.
Fixes: #24840
Inspired-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Replace old-style `file(APPEND .../CMake{Output,Error}.log)` logging
with calls to `message(CONFIGURE_LOG)` to record the steps in the
`CMakeConfigureLog.yaml` configure log instead.
Issue: #23200
LLVM Flang (https://github.com/llvm/llvm-project/tree/main/flang) is an LLVM
Fortran compiler that shares the same name as Flang (also known as Classic
Flang). Classic Flang is in active development and is already identified by
CMake as Flang. As such, LLVM Flang will be identified as `LLVMFlang`.
Fixes: #22387
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.
The `MINGW` variable indicates that the compiler targets MinGW, a GNU
ABI on Windows. Since commit aff3147917 (Modernize GNU compiler info on
Windows, 2009-12-02, v2.8.2~636), we load the `Platform/Windows-GNU`
module for compilers targetin MinGW, so set the variable there instead.
This is equivalent to `Platform/Windows-MSVC` setting the `MSVC`
variable. Also remove `if(MINGW)` checks from the module, which have
not been necessary since the enclosed logic was moved to that module.
The undocumented `CMAKE_COMPILER_IS_MINGW` internal variable is now
unused, so remove it too.
Fixes: #22647
These are set by modules loaded for `CMAKE_SYSTEM_NAME`. We do not
need to set them again if the compiler defines `__CYGWIN__`.
Also remove the now-unused undocumented `CMAKE_COMPILER_IS_CYGWIN`
internal variable.
Using a single ID 'IntelLLVM' for the suite of Intel compilers based on
the LLVM backend. The 'IntelLLVM' ID are used for C, C++, and Fortran.
Data Parallel C++ will be handled in a separate commit.
The C and C++ definitions are based on the Clang definitions. The Intel
LLVM-based C and C++ compilers are based on the Clang front end, so
existing Clang options are more likely to be a good match than options
for the older Intel compilers.
Fortran is based on the older Fortran front end with the LLVM backend.
It has a similar interface to the older versions, though many options
are shared with the C and C++ compilers.
Fixes: #21561
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
Capture CMAKE_<LANG>_COMPILER_ARG1 from CMAKE_<LANG>_COMPILER in the
same fashion that it is from $ENV{<LANG>}.
Since get_filename_component() returns a single string of all the
arguments from $ENV{<LANG>}, a single string of arguments will be
constructed from the items contained in CMAKE_<LANG>_COMPILER.
Fixes#20089
The Ninja generator's support for Fortran requires that source files
be preprocessed explicitly first. However, the `xlf` compiler does
not have a simple `-E` option or equivalent to do preprocessing.
The only documented way to get preprocessed output is to use `-d`
to leave it behind, but only at an inflexible location.
Instead, create our own `cpp` wrapper script and substitute it for the
real preprocessor using `-tF -B ...`. Teach the wrapper to map the
`cpp` output to the location we need and then invoke the real `cpp`
underneath.
Fixes: #19450
Typical Fortran compiler command-line tool names differ on Windows and
non-Windows platforms. Also, the name `ifc` should not be used on
Windows because there is an `ifc.exe` tool in Visual Studio that is
unrelated.
Fixes: #17752
The switch was not considering some languages, such as `ASM`.
Instead of memorizing the list of languages in the condition,
use a language specified by the includer.
Fixes: #17510
flang is a Fortran compiler built on top of clang [1]. Because flang
shares a lot of commonalities with clang, the flang module piggybacks
off the clang module and overrides certain options.
Add flang to Fortran compiler auto find list.
Update flang preprocessor macros to differentiate from PGI.
Add Flang-FindBinUtils.
[1] https://github.com/flang-compiler/flang
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.
Per-source copyright/license notice headers that spell out copyright holder
names and years are hard to maintain and often out-of-date or plain wrong.
Precise contributor information is already maintained automatically by the
version control tool. Ultimately it is the receiver of a file who is
responsible for determining its licensing status, and per-source notices are
merely a convenience. Therefore it is simpler and more accurate for
each source to have a generic notice of the license name and references to
more detailed information on copyright holders and full license terms.
Our `Copyright.txt` file now contains a list of Contributors whose names
appeared source-level copyright notices. It also references version control
history for more precise information. Therefore we no longer need to spell
out the list of Contributors in each source file notice.
Replace CMake per-source copyright/license notice headers with a short
description of the license and links to `Copyright.txt` and online information
available from "https://cmake.org/licensing". The online URL also handles
cases of modules being copied out of our source into other projects, so we
can drop our notices about replacing links with full license text.
Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority
of the replacements mechanically. Manually fix up shebang lines and trailing
newlines in a few files. Manually update the notices in a few files that the
script does not handle.
Rename Modules/Platform/<os>-<lang>.cmake files to
Modules/Platform/<os>-Determine-<lang>.cmake to clarify their role.
For compatibility with user-provided modules, load the old names
if they exist.
On mingw-w64 the GNU Fortran compiler does not define `__MINGW32__` or
any similar indicator. Fix `CMAKE_Fortran_PLATFORM_ID` detection in
this case by falling back to preprocessing a `.c` source file even
when the compiler id is already detected.
Move the Ld invocation match expression from CMakeDetermineCompilerId
into CMakeDetermine{C,CXX,Fortran}Compiler so that it can be specified
on a per-language basis.
The Concurrent Fortran compiler (ccur.com) is available on Linux and can
be used much like the GNU Fortran compiler. Currently it has no
preprocessor symbols to identify it so we need to detect it by matching
compiler output.
Suggested-by: Anthony Ette <Anthony.R.Ette@controlsdata.com>
Teach CMAKE_DETERMINE_COMPILER_ID to optionally try detecting the
compiler id using some given flags before trying to detect it with no
special flags. This will be useful for Fortran detection to distinguish
some compilers that use the preprocessors of others but have no macro of
their own by getting verbose output.
Fortran does not offer syntax to compose a string literal at
preprocessing time from numeric compuations. Instead encode each digit
of each component as a separate INFO string and compose them in CMake
code after extraction. Support MAJOR, MINOR, PATCH, and TWEAK
components with up to 8 digits each.
When testing CMAKE_<LANG>_COMPILER_ID values, do not explicitly
dereference or quote the variable. We want if() to auto-dereference the
variable and not its value. Also replace MATCHES with STREQUAL where
equivalent.
During cross-compiling the toolchain file may use CMakeForceCompiler to
force a compiler setting. When using the Xcode generator try to convert
it to a full path by searching the PATH as is done for the Makefile
generators.
Since commit 7d47c693 (Drop compatibility with CMake < 2.4, 2013-10-08)
we no longer need to use the configure_file IMMEDIATE option to support
compatibility modes less than 2.0.
When the user or toolchain file sets CMAKE_<LANG>_COMPILER to a name
without a path we use find_program with CMAKE_<LANG>_COMPILER_WITH_PATH
to search for the tool. Remove the temporary cache entry afterward to
avoid exposing it to projects. It is not set by other logic paths so no
one should be using it.
At the top of a build tree we configure inside the CMakeFiles directory
files such as "CMakeSystem.cmake" and "CMake<lang>Compiler.cmake" to
save information detected about the system and compilers in use. The
method of detection and the exact results store varies across CMake
versions as things improve. This leads to problems when loading files
configured by a different version of CMake. Previously we ignored such
existing files only if the major.minor part of the CMake version
component changed, and depended on the CMakeCache.txt to tell us the
last version of CMake that wrote the files. This led to problems if the
user deletes the CMakeCache.txt or we add required information to the
files in a patch-level release of CMake (still a "feature point" release
by modern CMake versioning convention).
Ensure that we always have version-consistent platform information files
by storing them in a subdirectory named with the CMake version. Every
version of CMake will do its own system and compiler identification
checks even when a build tree has already been configured by another
version of CMake. Stored results will not clobber those from other
versions of CMake which may be run again on the same tree in the future.
Loaded results will match what the system and language modules expect.
Rename the undocumented variable CMAKE_PLATFORM_ROOT_BIN to
CMAKE_PLATFORM_INFO_DIR to clarify its purpose. The new variable points
at the version-specific directory while the old variable did not.
Configure a hand-generated Xcode project to build the compiler id source
file since we cannot run the compiler command-line tool directly. Add a
post-build shell script phase to print out the compiler toolset build
setting. Run xcodebuild to compile the identification binary. Parse
the full path to the compiler tool from the xcodebuild output.
Re-organize CMakeDetermine(C|CXX|Fortran)Compiler.cmake to search for
the compiler command-line tool only under generators for which it makes
sense. For the Visual Studio generators we do not expect to find the
compiler tool from the environment, nor would we use the result anyway.
Furthermore, set CMAKE_${lang}_COMPILER_ID_TEST_FLAGS only when it has a
chance to be used. Extract _CMAKE_TOOLCHAIN_LOCATION from the compiler
path after running the compiler id step so in the future that step can
help find the path to the compiler.
