docs/manual/adding-packages-kconfig.txt

   1 // -*- mode:doc; -*-
   2 // vim: set syntax=asciidoc:
   3
   4 === Infrastructure for packages using kconfig for configuration files
   5
   6 A popular way for a software package to handle user-specified
   7 configuration is +kconfig+. Among others, it is used by the Linux
   8 kernel, Busybox, and Buildroot itself. The presence of a .config file
   9 and a +menuconfig+ target are two well-known symptoms of kconfig being
  10 used.
  11
  12 Buildroot features an infrastructure for packages that use kconfig for
  13 their configuration. This infrastructure provides the necessary logic to
  14 expose the package's +menuconfig+ target as +foo-menuconfig+ in
  15 Buildroot, and to handle the copying back and forth of the configuration
  16 file in a correct way.
  17
  18 The +kconfig-package+ infrastructure is based on the +generic-package+
  19 infrastructure. All variables supported by +generic-package+ are
  20 available in +kconfig-package+ as well. See
  21 xref:generic-package-reference[] for more details.
  22
  23 In order to use the +kconfig-package+ infrastructure for a Buildroot
  24 package, the minimally required lines in the +.mk+ file, in addition to
  25 the variables required by the +generic-package+ infrastructure, are:
  26
  27 ------------------------------
  28 FOO_KCONFIG_FILE = reference-to-source-configuration-file
  29
  30 $(eval $(kconfig-package))
  31 ------------------------------
  32
  33 This snippet creates the following make targets:
  34
  35 * +foo-menuconfig+, which calls the package's +menuconfig+ target
  36
  37 * +foo-update-config+, which copies the configuration back to the
  38   source configuration file. It is not possible to use this target
  39   when fragment files are set.
  40
  41 * +foo-update-defconfig+, which copies the configuration back to the
  42   source configuration file. The configuration file will only list the
  43   options that differ from the default values. It is not possible to
  44   use this target when fragment files are set.
  45
  46 and ensures that the source configuration file is copied to the build
  47 directory at the right moment.
  48
  49 There are two options to specify a configuration file to use, either
  50 +FOO_KCONFIG_FILE+ (as in the example, above) or +FOO_KCONFIG_DEFCONFIG+.
  51 It is mandatory to provide either, but not both:
  52
  53 * +FOO_KCONFIG_FILE+ specifies the path to a defconfig or full-config file
  54   to be used to configure the package.
  55
  56 * +FOO_KCONFIG_DEFCONFIG+ specifies the defconfig 'make' rule to call to
  57   configure the package.
  58
  59 In addition to these minimally required lines, several optional variables can
  60 be set to suit the needs of the package under consideration:
  61
  62 * +FOO_KCONFIG_EDITORS+: a space-separated list of kconfig editors to
  63   support, for example 'menuconfig xconfig'. By default, 'menuconfig'.
  64
  65 * +FOO_KCONFIG_FRAGMENT_FILES+: a space-separated list of configuration
  66   fragment files that are merged to the main configuration file.
  67   Fragment files are typically used when there is a desire to stay in sync
  68   with an upstream (def)config file, with some minor modifications.
  69
  70 * +FOO_KCONFIG_OPTS+: extra options to pass when calling the kconfig
  71   editors. This may need to include '$(FOO_MAKE_OPTS)', for example. By
  72   default, empty.
  73
  74 * +FOO_KCONFIG_FIXUP_CMDS+: a list of shell commands needed to fixup the
  75   configuration file after copying it or running a kconfig editor. Such
  76   commands may be needed to ensure a configuration consistent with other
  77   configuration of Buildroot, for example. By default, empty.