The extension flags enabled by commit v3.6.0-rc1~120^2~1 (Features:
Record standard flags for Intel C/C++ on Windows, 2016-04-18) of the
form `-Qstd=gnu++11` are not supported by the Intel C/C++ Compiler for
Windows. Fall back to using the non-extension form of the flags.
Issue: #16384
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.
All Fortran sources need to be preprocessed before any source may be
compiled so that module dependencies can be (later) extracted. Factor
out an explicit preprocessing step preceding compilation. Use Ninja
depfile dependencies on the preprocessing step and then compile the
already-preprocessed source with a separate build statement that depends
explicitly only on the preprocessor output. Later we will insert
dynamic discovery of module dependencies between these steps.
The Numerical Algorithms Group (NAG) Fortran compiler documents -PIC for
position-independent code and does not have a separate option for PIE.
We added `-PIC` for PIC in commit v2.8.11~174^2 (NAG: Use -PIC for
Fortran position-independent code, 2013-02-18). Follow up for PIE.
Closes: #16236
088f14eb Intel-C: standard flags are also supported in 12.0
27a3ca15 Intel-C: support gnu89 and gnu99 extension flags
cc223e1e Intel-C: declare support for gnu11
Without extensions, functions like `strdup` are not available since they
are actually controlled by feature flags such as _SVID_SOURCE and
_BSD_SOURCE. When using `-std=c11` on Intel, none of these flags are
set, so the functions are not declared properly leading to compile
errors.
Reported-by: Adam J. Stewart <ajstewart426@gmail.com>
Closes: #16226
This flag is needed for the `<LANG>_VISIBILITY_PRESET` target property.
It has been supported since GCC 4.0, not 4.2 as we previously recorded.
Fixes#16222.
Document these variables.
Change our convention for setting these variables from:
set(CMAKE_C_FLAGS_INIT "...")
to
string(APPEND CMAKE_C_FLAGS_INIT " ...")
so that any value previously set by a toolchain file will be used.
Automate the conversion with:
sed -i 's/set *(\(CMAKE_\(C\|CXX\|Fortran\|RC\|ASM\|${[^}]\+}\)_FLAGS\(_[^_]\+\)\?_INIT \+"\)/string(APPEND \1 /' \
Modules/Compiler/*.cmake Modules/Platform/*.cmake
and follow up with some manual fixes (e.g. to cases that already
meant to append). Also revert the automated changes to contexts
that are not protected from running multiple times.
Refactor options out of `Modules/Compiler/Intel-{ASM,C,CXX,Fortran}.cmake`
into a common helper in `Modules/Compiler/Intel.cmake`. Condition
them to be used only on non-Windows hosts where the Intel compiler
is GNU-like instead of MSVC-like.
Previously this worked only because the options were later overridden
by `Modules/Platform/Windows-Intel*.cmake`, but it is cleaner to not
set the options in the first place.
If e.g. libc.a is passed before any objects the linker raises the follwing
warning: cannot resolve archive libc.a to a compatible library, as no
input files have been encountered
In the end the library is skipped and missing symbols occur.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Versions below 12.1 do not provide enough information to properly detect
if compiling with c++98 or c++0x enabled so remove them from the
supported list.
This placeholder was added to the compilation rules for other languages
by commit v3.4.0-rc1~342^2 (Factor an <INCLUDES> placeholder out of
<FLAGS> in rule variables, 2015-07-13) but ASM was incorrectly left out.
Signed-off-by: Gregor Jasny <gjasny@googlemail.com>
When system-provided packages are upgraded we must re-compile sources
depending on their headers. Use `-MD` instead of `-MMD` so that the
generated depfiles do not exclude system headers.
Suggested-by: Jussi Judin
Due to #4662 -isystem support was disabled for all GNU Compilers
on Apple platforms. But the change was probably a just work around
for a broken compiler on Tiger (see 10837#c27206). So we tighten
the condition to only kick in for GCC versions earlier than 4.
That should ensure sane behavior for Xcode 3.2 and later.
The dependency flags require recent versions of `iccarm` and `iccavr`.
The multi-rule dependency generated with `--dependencies=m` does not
work well with Ninja, so use `--dependencies=ns` instead.
Drop the 'UNIX' condition on Clang compiler features. This enables
use of compile features with MinGW Clang, though additional work may
be needed for clang-cl.
When parsing implicit include dirs, link dirs, and link libs, all
arguments are resolved to absolute paths instead of relative paths.
This is correct for link and include directories but link libraries
should only include the library name, not it's path.
This is an extensive refactoring of the Cray compiler wrapper usage.
Using the new compiler wrapper checks, the CrayPrgEnv info files have
been moved from Platform/ to Compiler/. The adjusted naming convention
allows the compiler-wrapper information files to be loaded for both the
CrayLinuxEnvironment platform when cross-compiling and the Linux
platform if building natively on the Cray compute nodes. It also
creates a separation of common arguments for compiler id and language
information used to perform the appropriate introspection of implicit
arguments and libraries used by the compiler wrappers based on the
loaded module environment.
As per the following link:
http://docwiki.embarcadero.com/RADStudio/Seattle/en/Example_of_CODEGEARC_VERSION_Macro
The major/minor versions must be decoded as a hex string, while the patch
version must be decoded as a normal decimal string.
As an example, C++ Builder XE 8.1's bcc32.exe sets this macro to 0x070189C9.
The file version of bcc32.exe is 7.1.5570.35273. Therefore, the correct
interpretation to COMPILER_VERSION would be 7.1.35273.
Prior to commit v3.4.0-rc1~71^2 (Project: Determine default language
dialect for the compiler, 2015-09-15) we always guessed the default
language standard dialect based on the compiler version. This was not
reliable so that commit switched to computing the default language
standard dialect while detecting the compiler id.
When a toolchain file uses CMakeForceCompiler to set the compiler id
then the detection does not occur. Therefore commit v3.4.0-rc1~54^2
(Project: Don't require computed default dialect if compiler was forced,
2015-09-22) made the lack of detection an error only if the compiler was
not forced. However, this means that projects using CMakeForceCompiler
no longer even get the guess that we had before so <LANG>_COMPILER does
not work.
Due to the sophistication of CMake's compiler detection logic projects
should be ported away from using CMakeForceCompiler. In the meantime,
restore a guess of the default language standard dialect when the
compiler is forced.
Revert commit v3.4.0-rc1~10^2~2 (Features: Disable support for Oracle
SolarisStudio on non-Linux, 2015-09-29) and two follow-up commits.
The support of compile features and language standards on Orcale
SolarisStudio needs more investigation so for CMake 3.4 we should
just act as 3.3 did.
On SunOS the -std=c++11 flag must be used for linking as well as
compiling. Until we implement support for this we cannot support
the CXX_STANDARD property except on Linux (where it was tested).
The latter is now the preferred URL for visiting cmake.org with a
browser. Convert using the shell code:
git ls-files -z | xargs -0 sed -i 's|http://www\.cmake|https://cmake|g'
Ben Boeckel
Brad King
Neil Carlson
Chuck Atkins
Daniel Pfeifer
Alexander Stein
Geoff Viola
Robert Maynard
Levi Morrison
Gregor Jasny
Paweł Stankowski
Mariusz Pluciński
Juhani Simola
James Johnston
Joakim Andersson