Commit 28d49e17 authored by Arnd Bergmann's avatar Arnd Bergmann Committed by Masahiro Yamada
Browse files

Documentation: kbuild: explain handling optional dependencies 



This problem frequently comes up in randconfig testing, with
drivers failing to link because of a dependency on an optional
feature.

The Kconfig language for this is very confusing, so try to
document it in "Kconfig hints" section.

Reviewed-by: default avatarJavier Martinez Canillas <javierm@redhat.com>
Reviewed-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: default avatarNicolas Schier <nicolas@fjasle.eu>
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
parent fbf5892d

Documentation/kbuild/kconfig-language.rst

+26 −0
Original line number Diff line number Diff line
@@ -573,6 +573,32 @@ above, leading to: 
	bool "Support for foo hardware"

	depends on ARCH_FOO_VENDOR || COMPILE_TEST



Optional dependencies

~~~~~~~~~~~~~~~~~~~~~



Some drivers are able to optionally use a feature from another module

or build cleanly with that module disabled, but cause a link failure

when trying to use that loadable module from a built-in driver.



The most common way to express this optional dependency in Kconfig logic

uses the slightly counterintuitive::



  config FOO

	tristate "Support for foo hardware"

	depends on BAR || !BAR



This means that there is either a dependency on BAR that disallows

the combination of FOO=y with BAR=m, or BAR is completely disabled.

For a more formalized approach if there are multiple drivers that have

the same dependency, a helper symbol can be used, like::



  config FOO

	tristate "Support for foo hardware"

	depends on BAR_OPTIONAL



  config BAR_OPTIONAL

	def_tristate BAR || !BAR



Kconfig recursive dependency limitations

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~