summaryrefslogtreecommitdiffstats
path: root/Modules/Compiler/AppleClang-CXX.cmake
Commit message (Collapse)AuthorAgeFilesLines
* Compilers: Port to use default cmake_record_lang_compile_features macrosChuck Atkins2017-05-301-18/+0
|
* AppleClang: Use common compiler macros for language standard defaultChuck Atkins2017-05-021-12/+1
|
* Features: Activate C++ 17 support for AppleClang 6.1+Brad King2016-12-021-0/+8
|
* Features: Make feature recording conditions more consistentBrad King2016-12-021-2/+1
| | | | | | | | | Condition all calls to `_record_compiler_features_{c,cxx}` on `_result EQUAL 0` so that adding new language standards later does not need to update them. Avoid some duplicate compiler version checks by conditioning C11 and CXX14 feature recording on the existence of `CMAKE_{C11,CXX14}_STANDARD_COMPILE_OPTION` (whose setting already used the version check).
* Features: Centralize per-compiler recording macrosBrad King2016-11-021-7/+3
| | | | | Simplify and de-duplicate per-compiler feature recording macros and convert to a centralized per-language macro.
* Project: Guess default standard dialect if compiler was forced (#15852)Brad King2015-11-191-0/+3
| | | | | | | | | | | | | | | | | | | | | 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.
* Project: Don't require computed default dialect if compiler was forced.Stephen Kelly2015-09-221-3/+5
| | | | | | | | | | | | | | | | Commit 7235334a (Project: Determine default language dialect for the compiler., 2015-09-15) introduced a mechanism to determine the default dialect used for the running compiler. If conditions in the <CompilerId>-<Lang>.cmake file are such that compile features for that version of the compiler should be supported, the _DEFAULT_STANDARD is set to the computed value. However, the CMakeForceCompiler module allows users to bypass execution of the compiler by CMake. In that case, do not set the _DEFAULT_STANDARD variable at all, which effectively disables the compile-features where the module is used. No compile features have ever been recorded where the module is used so no functionality is lost.
* Project: Determine default language dialect for the compiler.Stephen Kelly2015-09-181-1/+5
| | | | | | Use the __cplusplus and __STDC_VERSION__ macros to automatically determine the default dialect for the compiler while determining its id and version.
* AppleClang: Use modern C++14 standard flags for Apple Clang 6.1Brad King2015-07-091-1/+4
| | | | | | | | The Apple Clang 6.1 compiler that comes with Xcode 6.3 is aware of the modern -std=c++14 and -std=gnu++14 flags, so use them instead of the "1y" flags. Suggested-by: darkapostle@rule506.net
* Features: Populate CMAKE_<LANG>_STANDARD_DEFAULT only for supported compilers.Stephen Kelly2015-02-041-1/+3
| | | | | | If no compiler feature information is known for a given compiler version, do not set a language standard default either. The two settings must be recorded consistently.
* AppleClang: Remove redundant UNIX condition.Stephen Kelly2015-02-041-1/+1
|
* Features: Ensure appropriate return value from feature test macros.Stephen Kelly2015-01-151-2/+1
| | | | | | | GNU-CXX already has complex logic and sets the _result to 0 before tests which may set it to something else. Change the other modules to be consistent with that.
* Features: Record for historical Xcode clang versions.Stephen Kelly2015-01-111-2/+5
|
* Features: Record dialect flags for AppleClang 4.0+.Stephen Kelly2015-01-111-1/+4
|
* Features: Record for AppleClang 5.1Stephen Kelly2014-12-221-0/+31
| | | | | Apple's Clang 5.1 already supports most of the C and C++ features CMake enumerates.
* Avoid if() quoted auto-dereference when checking for "MSVC"Fraser Hutchison2014-11-191-1/+1
| | | | | When testing CMAKE_<LANG>_COMPILER_ID values against "MSVC", do not allow the definition of the "MSVC" variable to be expanded.
* Don't load Clang-CXX from AppleClang-CXX.Stephen Kelly2014-04-071-1/+6
| | | | | The Clang-CXX module is going to get version-specific checks, and the version system for AppleClang is not the same as Clang.
* Clang: Add separate "AppleClang" compiler idBrad King2013-10-081-0/+1
Apple distributes their own Clang build with their own version numbers that differ from upstream Clang. Use the __apple_build_version__ symbol to identify the Apple Clang compiler and report the Apple Build Version as the fourth version component in CMAKE_<LANG>_COMPILER_VERSION. Add Compiler/AppleClang-<lang> and Platform/Darwin-AppleClang-<lang> modules that simply include the upstream equivalents. Fix comparisons of CMAKE_<LANG>_COMPILER_ID to Clang in CMake's own source and tests to account for AppleClang.
generated by cgit v0.12 at 2025-01-06 11:23:14 (GMT)