@@ -473,6 +473,24 @@ config option to 'y' no matter the dependencies.
The dependencies are moved to the symbol GENERIC_IOMAP and we avoid the
situation where select forces a symbol equals to 'y'.
+Adding features that need compiler support
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+There are several features that need compiler support. The recommended way
+to describe the dependency on the compiler feature is to use "depends on"
+followed by a test macro.
+
+config CC_STACKPROTECTOR
+ bool "Stack Protector buffer overflow detection"
+ depends on $(cc-option,-fstack-protector)
+ ...
+
+If you need to expose a compiler capability to makefiles and/or C source files,
+CC_HAS_ is the recommended prefix for the config option.
+
+config CC_HAS_STACKPROTECTOR_NONE
+ def_bool $(cc-option,-fno-stack-protector)
+
Build as module only
~~~~~~~~~~~~~~~~~~~~
To restrict a component build to module-only, qualify its config symbol
It would be nice if the source code is written in the same style. This proposes the convention for describing the compiler capability in Kconfig. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> --- This is not a technical issue, but it would be nice if everybody follows the same coding style. Without any documemation, people may write the code in their own way. For example, there could be some possibilities for the option naming. CC_HAS_ CC_SUPPORTS_ CC_HAVE_ ... IMHO, CC_HAS_ is short and enough to understand the meaning. CC_SUPPORTS_ is also good, but I personally prefer the shorter one. Comments are appreciated. Changes in v5: - Newly added Changes in v4: None Changes in v3: None Changes in v2: None Documentation/kbuild/kconfig-language.txt | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) -- 2.7.4