2014-08-03 17:32:41 +02:00
|
|
|
// -*- mode:doc; -*-
|
|
|
|
// vim: set syntax=asciidoc:
|
|
|
|
|
|
|
|
=== Infrastructure for packages using kconfig for configuration files
|
|
|
|
|
|
|
|
A popular way for a software package to handle user-specified
|
|
|
|
configuration is +kconfig+. Among others, it is used by the Linux
|
|
|
|
kernel, Busybox, and Buildroot itself. The presence of a .config file
|
|
|
|
and a +menuconfig+ target are two well-known symptoms of kconfig being
|
|
|
|
used.
|
|
|
|
|
|
|
|
Buildroot features an infrastructure for packages that use kconfig for
|
|
|
|
their configuration. This infrastructure provides the necessary logic to
|
|
|
|
expose the package's +menuconfig+ target as +foo-menuconfig+ in
|
|
|
|
Buildroot, and to handle the copying back and forth of the configuration
|
|
|
|
file in a correct way.
|
|
|
|
|
docs/manual: standardize references to the generic infra
Currently the text for each package infra that mentions the usage of
variables already provided by the generic infra diverge from each other:
- some (golang, kconfig, python) add a cross-referece to the generic
infra chapter;
- kconfig does not list any example;
- some mention _LICENSE as an example, others don't;
- some (cargo, golang, python) add an 'etc.' at the end of the examples,
giving the idea that can be more symbols provided by the generic
infra than the ones listed;
- most have the text 'works by defining a number of variables before
calling the +<macro-name>+ macro', except golang and kconfig;
- some actually list 'A few additional variables' but keep using some
old reference as 'An additional variable';
- some say 'First, all the package metadata' and other only 'All the
package metadata';
- most mention _SUBDIR as an example of variable supported by the
generic infra, even the generic infra manual not mentioning it.
Improve the correctness for the manual by standardizing the text among
the package infras:
- use the same text "All the package metadata information variables that
exist in the generic package infrastructure also exist in the
<name> infrastructure:" for all of them;
- add the cross-reference for all of them;
- remove the examples of variables inherited from the generic infra -
this also solves the _SUBDIR problem, there no longer is any reference
to _SUBDIR;
- wrap the modified text at 80 columns;
- add "macro" to golang and luarocks infra;
- use "A few additional variables" for qmake and waf.
At same time, add a missing format on golang manual for
BR2_PACKAGE_HOST_GO_HOST_ARCH_SUPPORTS.
Cc: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
[Arnout:
- remove the examples;
- add "the" where "macro" was added;
- rewrite the preceding paragraphs for kconfig to make it more
consistent.
]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 4286c89f9d987f5f3bcbb14dfd58ba440944f4c2)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2023-01-02 00:36:53 +01:00
|
|
|
The main macro of the kconfig package infrastructure is
|
|
|
|
+kconfig-package+. It is similar to the +generic-package+ macro.
|
|
|
|
|
|
|
|
Just like the generic infrastructure, the kconfig infrastructure works
|
|
|
|
by defining a number of variables before calling the +kconfig-package+
|
|
|
|
macro.
|
|
|
|
|
|
|
|
All the package metadata information variables that exist in the
|
|
|
|
xref:generic-package-reference[generic package infrastructure] also
|
|
|
|
exist in the kconfig infrastructure.
|
2014-08-03 17:32:41 +02:00
|
|
|
|
|
|
|
In order to use the +kconfig-package+ infrastructure for a Buildroot
|
|
|
|
package, the minimally required lines in the +.mk+ file, in addition to
|
|
|
|
the variables required by the +generic-package+ infrastructure, are:
|
|
|
|
|
2024-07-12 20:23:24 +02:00
|
|
|
----
|
2014-08-03 17:32:41 +02:00
|
|
|
FOO_KCONFIG_FILE = reference-to-source-configuration-file
|
|
|
|
|
|
|
|
$(eval $(kconfig-package))
|
2024-07-12 20:23:24 +02:00
|
|
|
----
|
2014-08-03 17:32:41 +02:00
|
|
|
|
|
|
|
This snippet creates the following make targets:
|
|
|
|
|
|
|
|
* +foo-menuconfig+, which calls the package's +menuconfig+ target
|
|
|
|
|
2015-04-28 16:34:31 +02:00
|
|
|
* +foo-update-config+, which copies the configuration back to the
|
|
|
|
source configuration file. It is not possible to use this target
|
|
|
|
when fragment files are set.
|
|
|
|
|
|
|
|
* +foo-update-defconfig+, which copies the configuration back to the
|
|
|
|
source configuration file. The configuration file will only list the
|
|
|
|
options that differ from the default values. It is not possible to
|
|
|
|
use this target when fragment files are set.
|
2014-08-03 17:32:41 +02:00
|
|
|
|
2019-08-05 08:43:01 +02:00
|
|
|
* +foo-diff-config+, which outputs the differences between the current
|
|
|
|
configuration and the one defined in the Buildroot configuration for
|
|
|
|
this kconfig package. The output is useful to identify the
|
|
|
|
configuration changes that may have to be propagated to
|
|
|
|
configuration fragments for example.
|
|
|
|
|
2014-08-03 17:32:41 +02:00
|
|
|
and ensures that the source configuration file is copied to the build
|
|
|
|
directory at the right moment.
|
|
|
|
|
2015-12-22 22:22:01 +01:00
|
|
|
There are two options to specify a configuration file to use, either
|
|
|
|
+FOO_KCONFIG_FILE+ (as in the example, above) or +FOO_KCONFIG_DEFCONFIG+.
|
|
|
|
It is mandatory to provide either, but not both:
|
|
|
|
|
|
|
|
* +FOO_KCONFIG_FILE+ specifies the path to a defconfig or full-config file
|
|
|
|
to be used to configure the package.
|
|
|
|
|
|
|
|
* +FOO_KCONFIG_DEFCONFIG+ specifies the defconfig 'make' rule to call to
|
|
|
|
configure the package.
|
|
|
|
|
2014-08-03 17:32:41 +02:00
|
|
|
In addition to these minimally required lines, several optional variables can
|
|
|
|
be set to suit the needs of the package under consideration:
|
|
|
|
|
|
|
|
* +FOO_KCONFIG_EDITORS+: a space-separated list of kconfig editors to
|
|
|
|
support, for example 'menuconfig xconfig'. By default, 'menuconfig'.
|
|
|
|
|
2015-04-28 16:34:31 +02:00
|
|
|
* +FOO_KCONFIG_FRAGMENT_FILES+: a space-separated list of configuration
|
|
|
|
fragment files that are merged to the main configuration file.
|
|
|
|
Fragment files are typically used when there is a desire to stay in sync
|
|
|
|
with an upstream (def)config file, with some minor modifications.
|
|
|
|
|
2014-09-27 21:32:47 +02:00
|
|
|
* +FOO_KCONFIG_OPTS+: extra options to pass when calling the kconfig
|
2014-09-27 21:32:38 +02:00
|
|
|
editors. This may need to include '$(FOO_MAKE_OPTS)', for example. By
|
2014-08-03 17:32:41 +02:00
|
|
|
default, empty.
|
|
|
|
|
|
|
|
* +FOO_KCONFIG_FIXUP_CMDS+: a list of shell commands needed to fixup the
|
|
|
|
configuration file after copying it or running a kconfig editor. Such
|
|
|
|
commands may be needed to ensure a configuration consistent with other
|
|
|
|
configuration of Buildroot, for example. By default, empty.
|
2016-09-17 14:45:36 +02:00
|
|
|
|
|
|
|
* +FOO_KCONFIG_DOTCONFIG+: path (with filename) of the +.config+ file,
|
|
|
|
relative to the package source tree. The default, +.config+, should
|
|
|
|
be well suited for all packages that use the standard kconfig
|
|
|
|
infrastructure as inherited from the Linux kernel; some packages use
|
|
|
|
a derivative of kconfig that use a different location.
|
core/pkg-kconfig: allow dependencies before configurators
Some users of kconfig need some packages to be built before their
kconfig infra be used.
For example, the linux kernel, starting with 4.16, needs flex and bison
to generate the parser code. Furthermore, starting with 4.18, it will
also need the cross-compiler before parsing the kconfig stuff, because
that calls the compiler to check its features.
Currently, this is broken, even the flex/bison ones, even though they
are listed, because there is no way to define dependencie that are
guaranteed before the (visual) configurators. For example:
$ make distclean
$ make menuconfig
--> enable the linux kernel, choose a defconfig, save, exit
$ make linux-menuconfig
[...]
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
YACC scripts/kconfig/zconf.tab.c
/bin/sh: bison: command not found
LEX scripts/kconfig/zconf.lex.c
scripts/Makefile.lib:196: recipe for target 'scripts/kconfig/zconf.tab.c' failed
make[3]: *** [scripts/kconfig/zconf.tab.c] Error 127
make[3]: *** Waiting for unfinished jobs....
/bin/sh: flex: command not found
scripts/Makefile.lib:188: recipe for target 'scripts/kconfig/zconf.lex.c' failed
make[3]: *** [scripts/kconfig/zconf.lex.c] Error 127
Makefile:528: recipe for target 'rpc_defconfig' failed
make[2]: *** [rpc_defconfig] Error 2
linux/linux.mk:511: recipe for target '/home/ymorin/dev/buildroot/buildroot/output/build/linux-4.17.11/.config' failed
make[1]: *** [/home/ymorin/dev/buildroot/buildroot/output/build/linux-4.17.11/.config] Error 2
Makefile:79: recipe for target '_all' failed
make: *** [_all] Error 2
So, we introduce a new type of dependencies for kconfig-based packages,
that are guaranteed to be built and installed before the (visual)
configurators are called.
Since those dependencies are phony targets and therefore always out of
date, a normal dependency would cause the .config target to be rebuilt
on each invocation of make. So we use an order-only pre-requisite, like
is done for the patch dependency.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Jan Kundrát <jan.kundrat@cesnet.cz>
Tested-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-08-17 18:06:49 +02:00
|
|
|
|
|
|
|
* +FOO_KCONFIG_DEPENDENCIES+: the list of packages (most probably, host
|
|
|
|
packages) that need to be built before this package's kconfig is
|
|
|
|
interpreted. Seldom used. By default, empty.
|
2021-07-24 23:19:21 +02:00
|
|
|
|
|
|
|
* +FOO_KCONFIG_SUPPORTS_DEFCONFIG+: whether the package's kconfig system
|
|
|
|
supports using defconfig files; few packages do not. By default, 'YES'.
|