d156f8f5a2 CompileFeatures: Record when MSVC gained full CXX14 support
62dbe53a8a CompileFeatures: Record when Intel gained full CXX14 support
1ebb0d79fe CompileFeatures: Relax cxx_relaxed_constexpr compiler requirements
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3292
Use the infrastructure added by commit 646fb1a646 (CompileFeatures:
memoize C++ compilers with full language level support, 2019-03-27) to
avoid using a `try_compile` to check for C++14 feature support when the
running compiler is known to have all features.
Use the infrastructure added by commit 646fb1a646 (CompileFeatures:
memoize C++ compilers with full language level support, 2019-03-27) to
avoid using a `try_compile` to check for C++14 feature support when the
running compiler is known to have all features.
Use the infrastructure added by commit 646fb1a646 (CompileFeatures:
memoize C++ compilers with full language level support, 2019-03-27) to
avoid using a `try_compile` to check for C++14 feature support when the
running compiler is known to have all features.
Use the infrastructure added by commit 646fb1a646 (CompileFeatures:
memoize C++ compilers with full language level support, 2019-03-27) to
avoid using a `try_compile` to check for C++14 feature support when the
running compiler is known to have all features.
Use the infrastructure added by commit 646fb1a646 (CompileFeatures:
memoize C++ compilers with full language level support, 2019-03-27) to
avoid using a `try_compile` to check for C++11 feature support when the
running compiler is known to have all features.
In commit 8e4899fd6c (CompileFeatures: Record which C features the MSVC
compiler supports, 2019-04-12) our `cmake_record_c_compile_features`
macro was accidentally left not setting the `_result` variable, which
had previously been set by `_record_compiler_features`. The variable is
expected by the call site in `cmake_determine_compile_features` and used
to switch between "failed" and "done" reports. Set it now.
Also record `c_variadic_macros` only for cl 14 (VS 2005) and higher
because it is not supported before that version.
SunPro 5.15 supports `-std=c++14` and several C++14 features.
SunPro 5.14 accepts `-std=c++14` but does not update its definition of
`__cplusplus` or any other macro to distinguish it from `-std=c++11`,
so we need to blacklist a couple features that do work but that we
cannot report for that version. We can still support `cxx_std_14`.
Co-Author: Robert Maynard <robert.maynard@kitware.com>
Use the infrastructure added by commit f92ccbc306
(CompileFeatures: memoize C compilers with full language level support)
to avoid using a `try_compile` to check for C 90/99/11 feature support when the running compiler is known to have a fixed set of feature support.
Use the infrastructure added by commit 646fb1a646 (CompileFeatures:
memoize C++ compilers with full language level support, 2019-03-27) to
avoid using a `try_compile` to check for C++98 feature support when the
running compiler is known to have all features.
613ac56e50 Add a test to verify meta-feature parity with granular features
b0f46c48f6 CompileFeatures: Now able to presume full language level support
646fb1a646 CompileFeatures: memoize C++ compilers with full language level support
0d641fcfad Tests: Remove outdated portion of CompileFeatures genex test
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3176
Previously compilers that only supported the meta-level flags
would not have any of the granular features listed. Now we
presume that they have full support and enable all the features.
Update granular feature tests to skip the actual compilation
checks for the presumed features.
Previously compilers that had full support for a language standard level
were still verified every time a new build directory was created. Now
we record this information and insert the correct granular compile
features instead of doing a `try_compile`.
Since commit 8f8d056051 (ARMCC: Fix identification of ARM compiler when
it defines GNU macros, 2019-03-20, v3.14.1~10^2) we consider ARMCC
before Clang or GNU compilers. Since armclang also defines
`__ARMCC_VERSION` it is now mistaken for ARMCC. Extend the check for
ARMCC to also verify that `__clang__` is not defined.
Issue: #19065
Previously compilers that had full support for a language
standard level was forced to verify this every time a new build
directory was created. Now we record this information and insert
the correct granular compile features instead of doing a try_compile.
d9d285c5ad jsoncpp: Fix include order for build within CMake
0d489fab19 libuv: fix atomic ops compilation with xlclang
1699f5c231 Utilities: Suppress warnings in third-party code when using XLClang
f709089d84 XLClang: Extract compiler implicit include directories
5c41386357 XLClang: Add policy CMP0089 to present as XL for compatibility
8278237933 XL: Remove overlap with the new XLClang compiler ID
6f5cf2d2c6 XL: Revert "Recognize compilers identified by __ibmxl__"
90c6156aa8 XLClang: Add a new compiler ID for the clang-based XL compiler
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2921
In commit 6555286c55 (XL: Add C and C++ language level flags,
2017-04-27, v3.9.0-rc1~184^2) we added support for both the traditional
XL compiler and the Clang-based variant used on Linux. The latter is
now handled by `Modules/Compiler/XLClang-{C,CXX}.cmake` using the
`XLClang` compiler id. Drop the corresponding content from the
traditional XL compiler modules.
Revert commit eb1a9be4b6 (XL: Recognize compilers identified by
__ibmxl__, 2018-03-05, v3.11.0-rc3~4^2). It is no longer needed because
we now use `__ibmxl__` to identify with compiler id `XLClang`.
In commit beb991110d (Remove now-unused code once used on IRIX,
2019-01-11, v3.14.0-rc1~167^2) we removed remnants of IRIX support.
Also remove remnants of MIPSpro compiler support.
CrayPrgEnv:
- add a new function __cmake_craype_linktype() that determines what
link mode the Cray compiler wrapper will use in a more sophisticated
way than just MATCHing for static/dynamic on the command line.
- add a new function __cmake_craype_setupenv() that does a
once-per-cmake-run setup that does the following:
1. does a basic check of the wrapper's configuration. Running
cmake and then changing module and/or linktype configuration
may cause build problems (since the data in the cmake cache
may no longer be correct after the change). We look for this
and warn the user about it.
2. uses the "module" provided PKG_CONFIG_PATH environment variable
to add additional prefixes to the system prefix path. This
function used to be done by CrayLinuxEnvironment using the
compiler implicit include/link paths but that is intended
only for cross-compiling on Cray front-end nodes. Since
CrayPrgEnv runs on both front-end and compute nodes, we
migrate this function here.
CrayLinuxEnvironment:
- No need to set variables like CMAKE_SHARED_LIBRARY_PREFIX to values
that have already been properly established by CMakeGenericSystem.cmake.
Remove redundant sets of CMAKE_SHARED_LIBRARY_PREFIX,
CMAKE_SHARED_LIBRARY_SUFFIX, CMAKE_STATIC_LIBRARY_PREFIX,
CMAKE_STATIC_LIBRARY_SUFFIX, CMAKE_FIND_LIBRARY_PREFIXES, and
CMAKE_DL_LIBS.
- No need to add $ENV{SYSROOT_DIR}/usr/include to CMAKE_SYSTEM_INCLUDE_PATH
when we already added $ENV{SYSROOT_DIR}/usr to CMAKE_SYSTEM_PREFIX_PATH.
- Remove __cray_list_intersect(), __list_clean_dupes(), and buggy
code that adds compiler implicit includes/libs to
CMAKE_SYSTEM_INCLUDE_PATH and CMAKE_SYSTEM_LIBRARY_PATH. This
function has migrated to CrayPrgEnv.cmake, as noted above.
See discussion in issue #17413 for additional details.
