| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Extend the change from commit e01990999a (Ninja: On Windows, select the
compiler occurring first in PATH, 2020-04-17, v3.18.0-rc1~291^2) to
apply to the MSYS/MinGW Makefiles generators too. Drop the implied
`gcc` and `g++` default compilers. This allows MinGW/Clang environments
to work out of the box.
Inspired-by: Mehdi Chinoune <mehdi.chinoune@hotmail.com>
Fixes: #23542
|
| |
|
|
|
|
|
|
|
|
|
| |
`CMAKE_<LANG>_COMPILER` may be a list if it was defined by a toolchain
file. In this case we move the args to `CMAKE_<LANG>_COMPILER_ARG1`.
If `CMAKE_<LANG>_COMPILER` is not a list, then it might have been cached
by a previous run that split the `CC` or `CXX` environment variable into
`CMAKE_<LANG>_COMPILER` and `CMAKE_<LANG>_COMPILER_ARG1`. In this
latter case, avoid clobbering `CMAKE_<LANG>_COMPILER_ARG1`.
Fixes: #23358
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since commit bd844387df (ROCMClang: Add the ROCm toolkit derived clang
compiler to CMake, 2020-08-28, v3.21.0-rc1~66^2~6) and commit ff0d2858e1
(HIP: Extract clang compiler details from hipcc, 2020-10-21,
v3.21.0-rc1~66^2~5), the separate `ROCMClang` compiler id for `hipcc`
has caused a few problems:
* The compiler id changed from behavior of CMake 3.20 and below,
breaking projects that already built with `hipcc` treated as `Clang`.
* The implementation of `target_compile_features` was incomplete for
the `ROCMClang` identity.
* Only `hipcc` was identified as `ROCMClang`, so after it is unwrapped
to the underlying `clang++`, future runs of new CMake versions on
an existing build tree would not repeat this.
* Clang should be usable as a HIP compiler without the `hipcc` wrapper.
Remove the `ROMClang` compiler identity, and revise HIP language support
to work directly with a Clang compiler.
Reject direct `hipcc` usage as a HIP compiler. For now it cannot be
supported because it interferes with flags CMake needs to pass to Clang.
Fixes: #22536, #22460, #22593
|
| |
|
|
|
|
| |
Previously, nvcc needed to be present in PATH or specified by CUDACXX.
On Windows with vcpkg, the PATH is heavily modified, which lead to
nvcc not being found with the Ninja generator.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
f76c20da63 Toolchain: Test compiler initial settings
db486da265 Toolchain: Update documentation for initial compiler flags
deec2f587c Toolchain: Take CMAKE_<lang>_FLAGS_INIT into account during compiler detection
ca899af3e2 Toolchain: Handle repeated invocations of CMake with -DCMAKE_C_COMPILER
12ba89e142 Toolchain: Make `/path/comp;-argn' behave the same as 'comp;-argn'
6f1af899db Toolchain: Capture all arguments from CMAKE_<LANG>_COMPILER
ec1d3bc0b6 cmake: avoid exception when printing "changed variables" message
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4136
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When using `cmake ... -DCMAKE_C_COMPILER=gcc;-pipe` first invocation of
CMake worked correctly.
When using `cmake ... -DCMAKE_C_COMPILER=/path/to/gcc;-pipe` first
invocation of CMake detected a change to CMAKE_C_COMPILER, printed "You
have changed variables" message, and re-ran the initial compiler tests
after configuration was complete and before generation of the project
files.
The difference was due to the cache being forced updated with the new
value of CMAKE_C_COMPILER so that the comparison check passes.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |/
|
|
|
|
|
|
|
|
| |
Since commit 8cc384f629 (Compilers: Add paths from -print-sysroot to
system prefix path, 2020-03-25, v3.18.0-rc1~337^2) we prepend the
compiler's sysroot to `CMAKE_SYSTEM_PREFIX_PATH`. This does not
make sense when the prefix is just `/`, such as on Ubuntu 16.04's
system compiler.
Fixes: #21019
|
| |
|
|
|
|
|
|
|
| |
Since commit 8cc384f629 (Compilers: Add paths from -print-sysroot to
system prefix path, 2020-03-25) we detect the compiler `-print-sysroot`
output and save it. On Windows, the value may include backslashes.
Convert the path to CMake's forward-slash convention for storage.
Fixes: #20679
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows, toolchains like MSVC require a set of environment variables
to be configured for the compiler to work correctly. The scripts that
prepare these environments typically put the compiler's directory ahead
of others in the `PATH`. Teach the Ninja generators to use this as a
heuristic to select the compiler when none is explicitly specified.
This is not necessary with Makefile generators because each toolchain's
environment comes with its own make tool variant, and the corresponding
Makefile generator (e.g. "NMake Makefiles") automatically implies the
matching compiler.
Fixes: #20585
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The compiler in the PATH on mac is a stub for a different delegate
depending on the environment. Rather than requiring xcode-select to
change the used Xcode globally, users should be able to choose the
compiler per-session. That is possible with the DEVELOPER_DIR
environment variable.
However, the environment can change between running CMake and invoking
the build. In such cases, CMake prefers to record the relevant paths
from the environment and use them when invoking the build. That is not
currently done for the compilers on APPLE, so the compiler used is not
the one reported when running cmake:
$ DEVELOPER_DIR=/Applications/Xcode2.app/Contents/Developer/ cc --version
Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
$ DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer/ cc --version
Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
Update that now by querying Xcode for the correct compiler path if
the compiler located by ordinary means is located in /usr/bin.
|
| |
|
|
| |
This will allow it to be re-used in multiple code paths later.
|
| |
|
|
|
|
|
| |
If find_program does not find CMAKE_<LANG>_COMPILER, use set_property()
to force the value to be that of CMAKE_<LANG>_COMPILER_INIT instead of
set(). This allows us to set the value without re-specifying the type
and documentation, thus preserving what find_program set.
|
| |
|
|
|
| |
Factor out a _cmake_find_compiler_path helper macro to avoid duplication
of the search for a full path to the compiler.
|
| |
|
|
|
|
|
|
|
|
| |
Teach modules CMakeDetermineCompiler and CMakeUnixFindMake to ask Xcode
where to find the compiler or make tools, using 'xcrun --find', if none
is found in the PATH. Teach module Platform/Darwin to add the path to
the SDK to CMAKE_SYSTEM_PREFIX_PATH so that find_* command look there.
Also add the SDK /usr/include directory to the implicit include list in
CMAKE_${lang}_IMPLICIT_INCLUDE_DIRECTORIES to suppress explicit -I
options for it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
