summaryrefslogtreecommitdiffstats
path: root/docs/manual/adding-packages-kconfig.txt
Commit message (Collapse)AuthorAgeFilesLines
* core/pkg-kconfig: allow dependencies before configuratorsYann E. MORIN2018-08-181-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* docs/manual: update pkg-kconfig doc about <pkg>_KCONFIG_DOTCONFIGThomas Petazzoni2016-09-171-0/+6
| | | | | | Content provided by Yann E. Morin. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* docs/manual: document the new kconfig-package variableYann E. MORIN2015-12-221-0/+10
| | | | | | | | | | | | | | The previous patch introduced the new FOO_KCONFIG_DEFCONFIG variable to specify a defconfig rule rather than a (def)config file. Add this to the manual. Also document the pre-existing FOO_KCONFIG_FILE for which the explanations were missing altogether. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Sam Bobroff <sam.bobroff@au1.ibm.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* kconfig-package: add support for config fragmentsFloris Bos2015-05-211-2/+13
| | | | | | | | | | | | | | | | | | | | | | | Adds functionality to the kconfig infrastructure to merge additional configuration fragment files to the main configuration file of kconfig packages, using support/kconfig/merge_config.sh Typical use-case is when you want your configuration to be kept in sync with an upstream (def)config file, but do require some minor local modifications. Disables -update-config and -update-defconfig targets when fragment files are set. [Thomas: take into account comments made by Arnout: - Minor fixes in the documentation changes - Add @ before the tests done in the $(1)-update-config and $(1)-update-defconfig targets.] Signed-off-by: Floris Bos <bos@je-eigen-domein.nl> Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Tested-by: Gergely Imreh <imrehg@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* packages: rename FOO_KCONFIG_OPT into FOO_KCONFIG_OPTSThomas De Schampheleire2014-10-041-1/+1
| | | | | | | | | | | | To be consistent with the recent change of FOO_MAKE_OPT into FOO_MAKE_OPTS, make the same change for FOO_KCONFIG_OPT. Sed command used: find * -type f | xargs sed -i 's#_KCONFIG_OPT\>#&S#g' Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* packages: rename FOO_MAKE_OPT into FOO_MAKE_OPTSThomas De Schampheleire2014-10-041-1/+1
| | | | | | | | | | | | | | | | | | | | | While the autotools infrastructure was using FOO_MAKE_OPT, generic packages were typically using FOO_MAKE_OPTS. This inconsistency becomes a problem when a new infrastructure is introduced that wants to make use of FOO_MAKE_OPT(S), and can live alongside either generic-package or autotools-package. The new infrastructure will have to choose between either OPT or OPTS, and thus rule out transparent usage by respectively generic packages or generic packages. An example of such an infrastructure is kconfig-package, which provides kconfig-related make targets. The OPTS variant is more logical, as there are typically multiple options. This patch renames all occurrences of FOO_MAKE_OPT in FOO_MAKE_OPTS. Sed command used: find * -type f | xargs sed -i 's#_MAKE_OPT\>#&S#g' Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* manual: add documentation for kconfig-packageThomas De Schampheleire2014-08-041-0/+56
This patch adds documentation for the new kconfig-package infrastructure to the manual. Note that due to the simplicity of the infrastructure, the documentation is not split in a 'tutorial' and a 'reference', like for the other infrastructures. Instead, the usage is described in one section. Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> [me: slight grammar fix 'copy -back- the configuration +back+ to...'] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
OpenPOWER on IntegriCloud