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
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.
The compiler identification message was modified in commit ea83d0f8fb
(IAR: Generalize and add support for IAR RX compiler, 2019-04-05) to
include the architecture id since IAR compilers are arch-specific.
Revise the logic to avoid modifying the message for other compilers.
MS-style command-line tools accept either `/` or `-` for command-line
options. Prefer `-` over `/` so that non-MS tools do not treat it as a
path.
Fixes: #18941
Add missing vendor table entries for Clang and AppleClang to identify
them. Previously this worked only if Clang was also enabled as a C or
CXX compiler first because we used to copy the C compiler id. However,
that was removed by commit v3.13.0-rc1~44^2 (ASM: Search for full path
even when using C or C++ compiler, 2018-09-26).
Fixes: #18575
When `CMAKE_{C,CXX}_COMPILER` is set but `CMAKE_ASM*_COMPILER` is
not, we copy the C or C++ compiler to use as the ASM compiler.
In this case we still need to search for the ASM compiler in case
the C or C++ compiler is not known as an absolute path.
Also do not copy the compiler id setting and let the normal detection
take place. The C compiler id may not exist if the language has not
been enabled.
Fixes: #18406
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
Make the implementation for this compiler more complete.
IAR has multiple C++ modes, historically they were reduced c++ versions
for embedded that gradually improved to the full standard (which can be
reduced again by e.g. disabling rtti and exceptions). The new
implementation picks the best available, but the c++ mode can also be
overridden by defining `CMAKE_IAR_CXX_FLAG`.
Add C/C++ standard flags so that all modes up to and including the last
supported standard are defined.
Fixes: #16826
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.
Clang may raise an error when passed a `-march=` option that doesn't
correspond to the current target triple. CMake cannot pass the target
triple when determining the compiler id because it doesn't know how yet,
but it does pass along user-specified flags. This breaks when those
user-specified flags include `-march=`. Fix this use case by also
trying to find the compiler id without the user-specified flags.
Fixes: #16587
Split the arguments off of the `ASM${ASM_DIALECT}` environment variable
as is done for `CC` and other compiler variables. This fixes using CMake
when `ASM*` is used to pass additional target flags, e.g. when one uses
`ASM=${CC}`.
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.
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.
This fixes#14210. In 2.8.10 CMakeDetermineCompiler.cmake was
modified (or added), and now the _INIT variable must not
be set to a list anymore, before it worked.
Alex
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.
Ancient versions of CMake required else(), endif(), and similar block
termination commands to have arguments matching the command starting the
block. This is no longer the preferred style.
Run the following shell code:
for c in else endif endforeach endfunction endmacro endwhile; do
echo 's/\b'"$c"'\(\s*\)(.\+)/'"$c"'\1()/'
done >convert.sed &&
git ls-files -z -- bootstrap '*.cmake' '*.cmake.in' '*CMakeLists.txt' |
egrep -z -v '^(Utilities/cm|Source/kwsys/)' |
egrep -z -v 'Tests/CMakeTests/While-Endwhile-' |
xargs -0 sed -i -f convert.sed &&
rm convert.sed
Teach CMake to prefer the system default compiler automatically when no
compiler is specified. By default use "cc" for C, "CC" for C++, and
"f95" for Fortran. Load a new Platform/<os>-<lang>.cmake module to
allow each platform to specify for each language its system compiler
name(s) and/or exclude certain names.
Create Platform/(CYGWIN|Darwin|Linux|Windows)-CXX.cmake modules to
specify "c++" as the system C++ compiler name for these platforms. On
systems that use case-insensitive filesystems exclude C++ compiler names
that are distinguished from C compiler names only by case.
This will change the default compiler selection for existing build
scripts that do not specify a compiler when run on machines with
separate system and GNU compilers both installed in the PATH. We do not
make this change in default behavior lightly. However:
(1) If a given build really needs specific compilers one should specify
them explicitly e.g. by setting CC, CXX, and FC in the environment.
(2) The motivating case is to prefer the system Clang on newer OS X
systems over the older GNU compilers typically also installed. On
such systems the names "cc" and "c++" link to Clang. This is the
first platform known to CMake on which "c++" is not a GNU compiler.
The old behavior selected "gcc" for C and "c++" C++ and therefore
chooses GNU for C and Clang for C++ by default. The new behavior
selects GNU or Clang consistently for both languages on older or
newer OS X systems, respectively.
(3) Other than the motivating OS X case the conditions under which the
behavior changes do not tend to exist in default OS installations.
They typically occur only on non-GNU systems with manually-installed
GNU compilers.
(4) The consequences of the new behavior are not dire. At worst the
project fails to compile with the system compiler when it previously
worked with the non-system GNU compiler. Such failure is easy to
work around (see #1).
In short this change creates a more sensible default behavior everywhere
and fixes poor default behavior on a widely-used platform at the cost of
a modest change in behavior in less-common conditions.
The compiler candidate list selection and search code for C, C++, ASM,
and Fortran languages was duplicated across four modules. To look for
compilers adjacent to already-enabled languages the C and CXX modules
each used _CMAKE_USER_(C|CXX)_COMPILER_PATH and the ASM module used
_CMAKE_TOOLCHAIN_LOCATION. Since commit 4debb7ac (Bias Fortran compiler
search with C/C++ compilers, 2009-09-09) CMake prefers Fortran compilers
matching the vendor and directory of an enabled C or C++ compiler.
Factor out the common functionality among the four languages into a new
CMakeDetermineCompiler module. Generalize the Fortran implementation so
that all languages may each use the vendor and directory of the other
languages that have already been enabled. For now do not list any
vendor-specific names for C, C++, or ASM so that only the directory
preference is used for these languages (existing behavior).
