When using a VS generator with `-T llvm`, MSBuild relies on the "LLVM
Compiler Toolchain" VS Extension. This does not put `clang-cl` in the
`PATH` inside the build, and LLVM no longer provides a `cl` replacement
either. Therefore we need another way to extract the path to the
`CMAKE_{C,CXX}_COMPILER`. Fortunately the LLVM VS integration provides
a `$(ClangClExecutable)` macro we can reference to get the path.
Fixes: #18983
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
e8ee8cab97 Xcode: Completely disable code signing for compiler id detection
11da882a12 Apple: Introduce separate system name for iOS, tvOS, and watchOS
36cf44a7a3 Tests: Isolate RunCMake.XcodeProject per-device cases from host arch
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2392
- Remove code signing requirements for non-macOS
- Do not set deployment target for non-macOS
- Build static library for compiler feature detection for non-macOS
- Use framework to run CompilerId tests for watchOS
- Port tests to new SDK handling
- Add new Apple cross-compiling section to toolchain documentation
Closes: #17870
-- Detect GHS compiler and version
Detect ARCHITECTURE_ID for PPC / ARM / 86 targets
Detect PLATFORM_ID for Integrity and Integrity178 platforms
Using defines specified in the documents for the compilers: 201416 PPC / 201754 ARM / 201714 86
-- Fallback C/CXX compiler ID to GHS if not otherwise detected and using GHS MULTI generator
Works around issue with some GHS compilers not setting __ghs__ compiler define
-- Tweak Compiler ID checking so major id of 002017 is not replaced with 217
-- Prefer try_compile() library targets when testing for working GHS compilers
-- Avoid CMake errors if reading past end of file for checking if file is PE executable
Code for this was prototyped when ELF detection was added long ago but
left commented out. Use either MH_MAGIC or MH_CIGAM for the 32-bit
variant and use either or MH_MAGIC_64 or MH_CIGAM_64 for the 64-bit
variant.
The IAR 6.50.6 compiler places extra/truncated copies of the
compiler id `INFO:` strings into binaries with a prefix like
`?<Constant "`. Teach CMakeDetermineCompilerId to ignore them.
Fixes: #18333
Xcode 10 no longer populates `CURRENT_ARCH` with the current
architecture in shell scripts and instead uses `undefined_arch`.
Instead we must use `ARCHS`. It lists all architectures separated by
spaces.
Fixes: #18085
Add new `version=` parameter in the toolset setting to select the
version. Add variable `CMAKE_VS_PLATFORM_TOOLSET_VERSION` to hold the
version, if one is set (blank indicates default).
Fixes: #17549
The check added by commit v3.10.0-rc2~2^2 (Clang: Diagnose unsupported
GNU-like clang targeting MSVC ABI, 2017-10-10) is incorrectly detecting
clang-cl 6.0 as GNU-like. Currently cmake is testing if the clang
compiler accepts `--version` to see if it accepts GNU style flags.
However, with the latest llvm snapshot this also works for clang-cl:
> clang-cl --version
clang version 6.0.0 (trunk)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
So instead we should use the `/?` flag which fails with clang but
works with clang-cl:
> clang-cl /? &> /dev/null; echo $?
0
> clang /? &> /dev/null; echo $?
1
Fixes: #17518
The LLVM/Clang installer on Windows provides a `LLVM/bin` directory
containing `clang.exe` and `clang++.exe` command-line tools that have a
GNU-like command-line but target the MSVC ABI (instead of MinGW). We
do not support this combination, so diagnose and reject it explicitly.
Tell users what to do to use the `clang-cl.exe` tool instead.
Issue: #16439
Create a `CMAKE_<LANG>_COMPILER_VERSION_INTERNAL` variable to hold
a secondary/internal compiler version number detected at the same
time as the primary compiler version. This will be useful for some
compilers where we need such a number to determine correct usage.
Inspired-by: Stefan Andersson <tfosm@hotmail.com>
Suggested-by: Norbert Lange <norbert.lange@andritz.com>
Issue: #17264
With MSVC the Ninja generator extracts the `cl -showIncludes` prefix.
When MSVC is configured to have non-English output, e.g. via
`VSLANG=2052` in the environment, then `cl` prints the prefix encoded
for the current code page, which is not necessarily UTF-8 encoding.
Currently we fail to convert the prefix to our internal UTF-8 encoding,
but assume it is UTF-8 later.
While writing `rules.ninja`, the Ninja generator converts our internal
UTF-8 encoding to the current code page. The `msvc_deps_prefix =` line
needs to be encoded as the current code page so that `ninja` can match
in the output from `cl -showIncludes` during the build.
Prior to commit v3.9.0-rc1~47^2 (codecvt: Re-implement do_out and
do_unshift, 2017-05-25), the non-UTF-8 prefix extracted above was
written without noticing its incorrect internal encoding. The
`rules.ninja` file was successfully written, but possibly with a mangled
`msvc_deps_prefix`. Since that commit the output stream correctly
rejects the non-UTF-8 byte sequence and writing `rules.ninja` fails.
Fix this by correctly converting the `cl -showIncludes` output from the
current code page to our internal UTF-8 encoding.
Fixes: #17191
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.
During compiler identification, extract the Xcode `CURRENT_ARCH` value
and save it for later use by the Xcode generator in an internal compiler
information variable. This will be useful to know the locations of
object files when only one architecture is built.
77139e32 Swift: Simplify mixed test case to make it version agnostic
c03141c0 Swift: Default to Swift 3.0 with Xcode 8.3 and later
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !638
Make the `ClCompile` element name and `PostBuildEvent/Command` value
configurable. Move the current content into default values for the
corresponding variables.
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
Visual Studio provides toolchains that are themselves built for 32-bit
or 64-bit host architectures. By default it uses the 32-bit tools, but
it can be told to prefer the 64-bit tools on 64-bit hosts. Extend the
`CMAKE_GENERATOR_TOOLSET` specification to provide a way to request
use of the 64-bit host tools.
Closes: #15622
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 `.pbxproj` file must now specify a `SWIFT_VERSION` value.
Set it to the legacy value of "2.3" for now. Later this can
be made configurable (e.g. to "3.0").
We use file(GLOB) to load the list of files produced by compiling the
compiler identification source. Encode square brackets in the path to
the directory so that they are not treated as special characters in the
globbing expression. Otherwise we fail to find any files when the path
contains square brackets and the compiler id is unknown.
Reported-by: Esch Nigma <eschnigma@openmailbox.org>
We run MSVC-like compilers with the `/showIncludes` option and match the
output to extract the corresponding message. Fix the matching to
support compilers like `clang-cl` that print the message on the first
line such that it is not preceded by a newline.
LLVM-Issue: https://llvm.org/bugs/show_bug.cgi?id=27226
VS expects the platform to be just `Itanium`, so drop the incorrect
special case mapping it to `ia64`. This platform name has been wrong
since the logic was added by commit v2.8.10~148^2~8 (VS: Detect the
compiler id and tool location, 2012-08-16).
