diff --git a/cmake/org.eclipse.cdt.cmake.is.core.doc/doc/html/builtins-detection.xhtml b/cmake/org.eclipse.cdt.cmake.is.core.doc/doc/html/builtins-detection.xhtml index da100237195..ff1d8355b01 100644 --- a/cmake/org.eclipse.cdt.cmake.is.core.doc/doc/html/builtins-detection.xhtml +++ b/cmake/org.eclipse.cdt.cmake.is.core.doc/doc/html/builtins-detection.xhtml @@ -20,7 +20,7 @@ td {
CDT CMake support can detect compiler-built-in include paths and preprocessor macros.
Unfortunately, it has no knowledge about the generated build system structure, the compile_commads.json
file generated by CMake only reports source-files. To avoid the cost of running the built-ins detector for
- each source-file, CDT CMAke support assumes that compiler built-ins
+ each source-file, CDT CMake support assumes that compiler built-ins
are the same for each source-file in a CMake project. Therefore, detection is run just once
(on the first source file found per language) per Eclipse project.
- Please note that for performance reasons, compiler built-ins assumes that compiler built-ins
- are the same for each source-file in a CMake project and built-ins detection is run only for the
- first source-file.
- In contrast, CMake has commands like add_compile_options
, target_compile_features
and
- target_compile_options
allowing you to specify the language standard and
- non-standard system include paths on a
- per-source-directory or per-artifact level.
- Hence the syntax highlighting may not always exactly reflect the built-ins specified on that levels.
-
Remarks:
gcc -E -P -dM -Wp,-v emty.c
@@ -126,6 +116,6 @@ td {