summaryrefslogtreecommitdiffstats
path: root/Modules/Compiler/Clang-CXX.cmake
Commit message (Collapse)AuthorAgeFilesLines
* Clang: Refactor CXX standard flags into __compiler_clang_cxx_standards()Raul Tambre2020-04-071-118/+1
| | | | | | | These standard flags are the same for CXX, OBJCXX and CUDA. Refactor them into a single macro to reduce duplication and so we can easily reuse them. Updated bootstrap script to search in the general Clang module instead of the language-specific.
* clang-tidy: Add driver mode argumentHanjiang Yu2020-01-271-0/+3
| | | | | | | `clang-tidy` does not infer driver mode if it is not provided with a JSON compilation database. This is exactly the way cmake launches it. Hence clang-tidy will only use the default driver mode. Add an explicit driver mode argument to avoid this.
* Clang: For MSVC ABI do not use modes older than C++14Brad King2019-07-241-0/+7
| | | | | | | | | | | | | | | | | | | | Since commit d44c0db0b2 (clang: setup correct configuration in gnu mode, 2019-02-20, v3.15.0-rc1~41^2~5) we support the GNU-like Clang that targets the MSVC ABI. However, Clang cannot compile with the MSVC standard library unless it runs in a mode aware of C++14 (since MSVC itself does not even have a lower mode). When `CMAKE_CXX_STANDARD` is set to 98 or 11, use C++14 anyway. Since Clang's default mode is aware of C++14, another option is to not add any flags for 98 or 11. However, if a future Clang version ever defaults to a higher C++ standard, setting the standard to 98 or 11 should at least not use a mode higher than 14. Also revert test updates from commit 4819ff9647 (Tests: fix failures with gnu mode clang on windows, 2019-03-21, v3.15.0-rc1~41^2~3) that were meant to work around the standard selection problem. Fixes: #19496
* clang: setup correct configuration in gnu modeZsolt Parragi2019-05-231-2/+11
|
* CompileFeatures: Record when compilers gained full CXX14 supportRobert Maynard2019-05-021-0/+2
| | | | | | | 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.
* CompileFeatures: Record when compilers gained full CXX11 supportRobert Maynard2019-04-291-1/+2
| | | | | | | 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.
* CompileFeatures: Record when CXX compilers have gained full support for 98Robert Maynard2019-04-111-0/+2
| | | | | | | 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.
* Clang: Add standard flags support when simulating MSVCRuben Van Boxem2018-04-111-0/+21
| | | | | | | When Clang 3.9 simulates MSVC 19.0 or higher it knows the `-std:` flags that such versions of MSVC defines. Fixes: #17866
* Clang: Avoid extra C++ feature detection when simulating MSVCBrad King2018-04-111-0/+15
| | | | | | | | Apply the optimization from commit v3.10.0-rc1~131^2 (MSVC: Avoid unnecessary C++ feature detection steps, 2017-09-11) to the case of Clang simulating a version of MSVC that does not define standards. Issue: #17274
* Clang: Refactor standard flags logic when simulating MSVCBrad King2018-04-111-5/+6
| | | | | Consolidate the compile options and standard defaults branches. Add comments.
* Android: Do not pass non-existent Clang -std flagsBrad King2018-04-021-2/+9
| | | | | | | | | | | | | | | Android NDK r16b comes with Android clang version 5.0.300080 (based on LLVM 5.0.300080) Although it claims version 5, it does not support the `-std=c++17` or `-std=c++2a` flags that upstream Clang does. Android NDK r17-beta1 comes with Android (4639204 based on r316199) clang version 6.0.1 that does have the flags.
* Features: Activate C++ 20 support for Clang 5.0+Brad King2018-03-271-0/+5
|
* Features: Add infrastructure for C++ 20 language standardBrad King2018-03-271-0/+2
| | | | Issue: #17849
* Features: Use -std=c++17 for C++ 17 on Clang 5.0+Brad King2018-03-261-1/+4
| | | | Clang 5.0 added support for the `-std=c++17` flag.
* Clang: Do not add '-std=' options when simulating MSVCRuben Van Boxem2017-06-271-22/+38
| | | | | | | The `cl.exe` style command line does not accept the `-std=` options. Instead behave like MSVC where we don't define standard levels. Fixes: #16266
* Clang: Fix language defaults for 2.1Chuck Atkins2017-05-301-1/+1
|
* Compilers: Port to use default cmake_record_lang_compile_features macrosChuck Atkins2017-05-301-18/+0
|
* Clang: Use common compiler macros for language standard defaultChuck Atkins2017-05-021-11/+1
|
* Features: activate C++11 support for Clang 3.1+Giel van Schijndel2017-01-121-3/+3
|
* Features: Activate C++ 17 support for Clang 3.5+Brad King2016-12-021-0/+8
|
* Features: Make feature recording conditions more consistentBrad King2016-12-021-1/+3
| | | | | | | | | 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.
* Record compile features for MinGW Clang on Windows (#15897)Brad King2016-01-111-2/+2
| | | | | | 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.
* 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-2/+5
| | | | | | Use the __cplusplus and __STDC_VERSION__ macros to automatically determine the default dialect for the compiler while determining its id and version.
* 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.
* 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.
* 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.
* Features: Use the correct dialect flag when recording features.Stephen Kelly2014-11-121-4/+4
| | | | | Avoid using -std=c++1y for compilers which support -std=c++14, for example.
* Clang: Enable c++14 dialect flag with Clang 3.5.Stephen Kelly2014-09-171-1/+4
|
* Clang: Don't overwrite c++11 compile option value with c++14 flag.Stephen Kelly2014-09-171-2/+2
|
* Features: Record for Clang 3.4Stephen Kelly2014-05-201-1/+26
| | | | Clang 3.4 supports all features currently known to CMake.
* Features: Only require AppleClang policy to be NEW on APPLE.Stephen Kelly2014-05-141-1/+1
|
* Add some COMPILE_OPTIONS for specifying C++ dialect.Stephen Kelly2014-04-071-0/+13
| | | | | These are compiler-specific, compiler version specific, extension specific and standard version specific.
* Don't load Clang-CXX from AppleClang-CXX.Stephen Kelly2014-04-071-0/+5
| | | | | The Clang-CXX module is going to get version-specific checks, and the version system for AppleClang is not the same as Clang.
* Clang: Support Windows variants for GNU and MSVC (#13035, #14458)Brad King2013-10-041-1/+3
| | | | | | | | | | | | | | | | Teach the compiler identification preprocessor tests to report when Clang simulates MSVC, and what version. If not MSVC, assume GNU. Teach compiler information modules Clang-(C|CXX) to recognize when Clang simulates MSVC and skip loading the GNU information. Teach the Windows-MSVC platform information to recognize when it is loaded as the simulated compiler and use that version information instead of the real compiler's (different) version scheme. Add platform modules Windows-Clang-(C|CXX) and support module Windows-Clang to load either Windows-MSVC or Windows-GNU and wrap the corresponding information macros.
* Add a COMPILE_OPTION for a VISIBILITY_INLINES_HIDDEN target property.Stephen Kelly2013-06-021-0/+2
| | | | | | | This corresponds to the g++ and clang++ option -fvisibility-inlines-hidden on linux. On Windows with MinGW, this corresponds to -fno-keep-inline-dllexport. That option is not supported by clang currently.
* Clang: Split Compiler/Clang* modules out from GNU (#13550)Brad King2012-09-191-1/+2
| | | | | | | While Clang presents an almost identical interface to GNU there will be some differences. Split the compiler information modules to allow separate rules for Clang. Start by loading the GNU rules but leave a place to add Clang-specific information.
* Recognize Clang C and C++ compilers (see #10693)Brad King2010-05-171-0/+1
Map to the platform and compiler information for GNU because the compilers are command-line compatible for common operations. Later we can add Clang-specific features as necessary. We honor the preferred capitalization is "Clang", not the common mis-spelling "CLang".
generated by cgit v0.12 at 2025-09-15 03:42:59 (GMT)