infra: introduce a kconfig-package infrastructure
There are several packages that have a configuration file managed by
kconfig: uclibc, busybox, linux and barebox. All these packages need some
make targets to handle the kconfig specificities: creating a configuration
(menuconfig, ...) and saving it back (update-config, ...)
These targets should be the same for each of these packages, but
unfortunately they are not. Especially with respect to saving back the
configuration to the original config file, there are many differences.
A previous set of patches fixed these targets for the uclibc package.
This patch extracts these targets into a common kconfig-package
infrastructure, with the goals of:
- aligning the behavior of all kconfig-based packages
- removing code duplication
In order to use this infrastructure, a package should at a minimum specify
FOO_KCONFIG_FILE and eval the kconfig-package macro. The supported
configuration editors can be set with FOO_KCONFIG_EDITORS and defaults to
menuconfig only.
Additionally, a package can specify FOO_KCONFIG_OPT for extra options to
pass to the invocation of the kconfig editors, and FOO_KCONFIG_FIXUP_CMDS
for a list of shell commands used to fixup the .config file after a
configuration has been created/edited.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
[yann.morin.1998@free.fr: add missing 4th argument when calling to
inner-kconfig-package (namely, 'target']
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-08-03 17:32:40 +02:00
|
|
|
################################################################################
|
|
|
|
# Kconfig package infrastructure
|
|
|
|
#
|
|
|
|
# This file implements an infrastructure that eases development of
|
|
|
|
# package .mk files for packages that use kconfig for configuration files.
|
|
|
|
# It is based on the generic-package infrastructure, and inherits all of its
|
|
|
|
# features.
|
|
|
|
#
|
|
|
|
# See the Buildroot documentation for details on the usage of this
|
|
|
|
# infrastructure.
|
|
|
|
#
|
|
|
|
################################################################################
|
|
|
|
|
2017-12-01 16:09:44 +01:00
|
|
|
# Macro to update back the custom (def)config file
|
|
|
|
# $(1): file to copy from
|
|
|
|
define kconfig-package-update-config
|
|
|
|
@$(if $($(PKG)_KCONFIG_FRAGMENT_FILES), \
|
|
|
|
echo "Unable to perform $(@) when fragment files are set"; exit 1)
|
|
|
|
@$(if $($(PKG)_KCONFIG_DEFCONFIG), \
|
|
|
|
echo "Unable to perform $(@) when using a defconfig rule"; exit 1)
|
infra/pkg-kconfig: do not update-(def)config to a directory
Currently, if the user specifies the path to an existing directory as
the path to the custom (def)config file (FOO_KCONFIG_FILE), then we
happily create a file in there, either 'defconfig' or '.config' (or
whatever the .config is named for that package), depending on whether
we're saving a defconfig or a full config.
So, we could save the file, but then the Buildroot defconfig file that
contains that path would no longer be reusable as-is, because we
interpret that path as a path to a file.
Furthermore, if the directory-portion of FOO_KCONFIG_FILE does not
exist yet, the update would fail, because cp does not create missing
directory components.
So we fix that by adding an explicit test for the directory-ness of the
target file, and then an explicit mkdir to create missing directory
components.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2017-12-01 16:09:46 +01:00
|
|
|
$(Q)if [ -d $($(PKG)_KCONFIG_FILE) ]; then \
|
|
|
|
echo "Unable to perform $(@) when $($(PKG)_KCONFIG_FILE) is a directory"; \
|
|
|
|
exit 1; \
|
|
|
|
fi
|
|
|
|
$(Q)mkdir -p $(dir $($(PKG)_KCONFIG_FILE))
|
2017-12-01 16:09:44 +01:00
|
|
|
cp -f $($(PKG)_DIR)/$(1) $($(PKG)_KCONFIG_FILE)
|
2019-05-30 20:09:09 +02:00
|
|
|
$(Q)touch --reference $($(PKG)_DIR)/$($(PKG)_KCONFIG_STAMP_DOTCONFIG) $($(PKG)_KCONFIG_FILE)
|
2017-12-01 16:09:44 +01:00
|
|
|
endef
|
|
|
|
|
package/pkg-kconfig: pass HOSTCC during kconfig steps
The kconfig build logic uses the HOSTCC variable to find the host
compiler. It makes sense to explicitly pass a value to this variable,
pointing to the host compiler used by Buildroot.
During the kconfig step, host-ccache is not ready (host-ccache is only
a dependency to the configure step of packages), so we use
$(HOSTCC_NOCCACHE).
Packages currently using the kconfig-package fell into two categories:
- Those not passing any HOSTCC value. For such packages, it was the
default host compiler detected by the kconfig build logic that was
used. ccache was therefore never used. With this commit, those
packages will now be using the host compiler detected by
Buildroot. Packages in this situation: at91bootstrap3, barebox,
busybox, swupdate, uclibc, xvisor.
- Those passing a HOSTCC value. Such packages were passing $(HOSTCC),
which doesn't work as host-ccache will not be ready. This commit
does not fix them, as they still override HOSTCC. It will be fixed
in followup commits. Packages in this situation: uboot and
linux. Note that linux was a bit special, because it has a
KCONFIG_DEPENDENCIES on the toolchain package, so in fact
host-ccache was ready.
So practically speaking, this commit does not fix anything, as the two
only problematic packages that use $(HOSTCC) are not fixed. However,
it makes things more correct by explicitly telling kconfig which
compiler to use.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-01-10 22:14:58 +01:00
|
|
|
PKG_KCONFIG_COMMON_OPTS = \
|
|
|
|
HOSTCC=$(HOSTCC_NOCCACHE)
|
|
|
|
|
2018-09-21 15:55:20 +02:00
|
|
|
# Macro to save the defconfig file
|
|
|
|
# $(1): the name of the package in upper-case letters
|
|
|
|
define kconfig-package-savedefconfig
|
2020-08-04 21:00:04 +02:00
|
|
|
$($(1)_MAKE_ENV) $($(1)_MAKE) -C $($(1)_DIR) \
|
2018-09-21 15:55:20 +02:00
|
|
|
$(PKG_KCONFIG_COMMON_OPTS) $($(1)_KCONFIG_OPTS) savedefconfig
|
|
|
|
endef
|
|
|
|
|
|
|
|
# The correct way to regenerate a .config file is to use 'make olddefconfig'.
|
|
|
|
# For historical reasons, the target name is 'oldnoconfig' between Linux kernel
|
|
|
|
# versions 2.6.36 and 3.6, and remains as an alias in later versions.
|
|
|
|
# In older versions, and in some other projects that use kconfig, the target is
|
|
|
|
# not supported at all, and we use 'yes "" | make oldconfig' as a fallback
|
|
|
|
# only, as this can fail in complex cases.
|
|
|
|
# $(1): the name of the package in upper-case letters
|
|
|
|
define kconfig-package-regen-dot-config
|
|
|
|
$(if $(filter olddefconfig,$($(1)_KCONFIG_RULES)),
|
|
|
|
$(Q)$($(1)_KCONFIG_MAKE) olddefconfig,
|
|
|
|
$(if $(filter oldnoconfig,$($(1)_KCONFIG_RULES)),
|
|
|
|
$(Q)$($(1)_KCONFIG_MAKE) oldnoconfig,
|
|
|
|
$(Q)(yes "" | $($(1)_KCONFIG_MAKE) oldconfig)))
|
|
|
|
endef
|
|
|
|
|
2018-09-21 15:55:21 +02:00
|
|
|
# Macro to create a .config file where all given fragments are merged into.
|
|
|
|
# $(1): the name of the package in upper-case letters
|
|
|
|
# $(2): name of the .config file
|
|
|
|
# $(3): fragment files to merge
|
|
|
|
define kconfig-package-merge-config
|
|
|
|
$(Q)$(if $($(1)_KCONFIG_DEFCONFIG),\
|
|
|
|
$($(1)_KCONFIG_MAKE) $($(1)_KCONFIG_DEFCONFIG),\
|
|
|
|
$(INSTALL) -m 0644 -D $($(1)_KCONFIG_FILE) $(2))
|
|
|
|
$(Q)support/kconfig/merge_config.sh -m -O $(dir $(2)) $(2) $(3)
|
|
|
|
$(call kconfig-package-regen-dot-config,$(1))
|
|
|
|
endef
|
|
|
|
|
infra: introduce a kconfig-package infrastructure
There are several packages that have a configuration file managed by
kconfig: uclibc, busybox, linux and barebox. All these packages need some
make targets to handle the kconfig specificities: creating a configuration
(menuconfig, ...) and saving it back (update-config, ...)
These targets should be the same for each of these packages, but
unfortunately they are not. Especially with respect to saving back the
configuration to the original config file, there are many differences.
A previous set of patches fixed these targets for the uclibc package.
This patch extracts these targets into a common kconfig-package
infrastructure, with the goals of:
- aligning the behavior of all kconfig-based packages
- removing code duplication
In order to use this infrastructure, a package should at a minimum specify
FOO_KCONFIG_FILE and eval the kconfig-package macro. The supported
configuration editors can be set with FOO_KCONFIG_EDITORS and defaults to
menuconfig only.
Additionally, a package can specify FOO_KCONFIG_OPT for extra options to
pass to the invocation of the kconfig editors, and FOO_KCONFIG_FIXUP_CMDS
for a list of shell commands used to fixup the .config file after a
configuration has been created/edited.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
[yann.morin.1998@free.fr: add missing 4th argument when calling to
inner-kconfig-package (namely, 'target']
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-08-03 17:32:40 +02:00
|
|
|
################################################################################
|
|
|
|
# inner-kconfig-package -- generates the make targets needed to support a
|
|
|
|
# kconfig package
|
|
|
|
#
|
|
|
|
# argument 1 is the lowercase package name
|
|
|
|
# argument 2 is the uppercase package name, including a HOST_ prefix
|
|
|
|
# for host packages
|
|
|
|
# argument 3 is the uppercase package name, without the HOST_ prefix
|
|
|
|
# for host packages
|
|
|
|
# argument 4 is the type (target or host)
|
|
|
|
################################################################################
|
|
|
|
|
|
|
|
define inner-kconfig-package
|
|
|
|
|
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
|
|
|
# Register the kconfig dependencies as regular dependencies, so that
|
|
|
|
# they are also accounted for in the generated graphs.
|
|
|
|
$(2)_DEPENDENCIES += $$($(2)_KCONFIG_DEPENDENCIES)
|
|
|
|
|
infra: introduce a kconfig-package infrastructure
There are several packages that have a configuration file managed by
kconfig: uclibc, busybox, linux and barebox. All these packages need some
make targets to handle the kconfig specificities: creating a configuration
(menuconfig, ...) and saving it back (update-config, ...)
These targets should be the same for each of these packages, but
unfortunately they are not. Especially with respect to saving back the
configuration to the original config file, there are many differences.
A previous set of patches fixed these targets for the uclibc package.
This patch extracts these targets into a common kconfig-package
infrastructure, with the goals of:
- aligning the behavior of all kconfig-based packages
- removing code duplication
In order to use this infrastructure, a package should at a minimum specify
FOO_KCONFIG_FILE and eval the kconfig-package macro. The supported
configuration editors can be set with FOO_KCONFIG_EDITORS and defaults to
menuconfig only.
Additionally, a package can specify FOO_KCONFIG_OPT for extra options to
pass to the invocation of the kconfig editors, and FOO_KCONFIG_FIXUP_CMDS
for a list of shell commands used to fixup the .config file after a
configuration has been created/edited.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
[yann.morin.1998@free.fr: add missing 4th argument when calling to
inner-kconfig-package (namely, 'target']
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-08-03 17:32:40 +02:00
|
|
|
# Call the generic package infrastructure to generate the necessary
|
|
|
|
# make targets.
|
|
|
|
# Note: this must be done _before_ attempting to use $$($(2)_DIR) in a
|
|
|
|
# dependency expression
|
|
|
|
$(call inner-generic-package,$(1),$(2),$(3),$(4))
|
|
|
|
|
|
|
|
# Default values
|
2020-08-04 21:00:04 +02:00
|
|
|
$(2)_MAKE ?= $$(MAKE)
|
infra: introduce a kconfig-package infrastructure
There are several packages that have a configuration file managed by
kconfig: uclibc, busybox, linux and barebox. All these packages need some
make targets to handle the kconfig specificities: creating a configuration
(menuconfig, ...) and saving it back (update-config, ...)
These targets should be the same for each of these packages, but
unfortunately they are not. Especially with respect to saving back the
configuration to the original config file, there are many differences.
A previous set of patches fixed these targets for the uclibc package.
This patch extracts these targets into a common kconfig-package
infrastructure, with the goals of:
- aligning the behavior of all kconfig-based packages
- removing code duplication
In order to use this infrastructure, a package should at a minimum specify
FOO_KCONFIG_FILE and eval the kconfig-package macro. The supported
configuration editors can be set with FOO_KCONFIG_EDITORS and defaults to
menuconfig only.
Additionally, a package can specify FOO_KCONFIG_OPT for extra options to
pass to the invocation of the kconfig editors, and FOO_KCONFIG_FIXUP_CMDS
for a list of shell commands used to fixup the .config file after a
configuration has been created/edited.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
[yann.morin.1998@free.fr: add missing 4th argument when calling to
inner-kconfig-package (namely, 'target']
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-08-03 17:32:40 +02:00
|
|
|
$(2)_KCONFIG_EDITORS ?= menuconfig
|
2014-09-27 21:32:47 +02:00
|
|
|
$(2)_KCONFIG_OPTS ?=
|
infra: introduce a kconfig-package infrastructure
There are several packages that have a configuration file managed by
kconfig: uclibc, busybox, linux and barebox. All these packages need some
make targets to handle the kconfig specificities: creating a configuration
(menuconfig, ...) and saving it back (update-config, ...)
These targets should be the same for each of these packages, but
unfortunately they are not. Especially with respect to saving back the
configuration to the original config file, there are many differences.
A previous set of patches fixed these targets for the uclibc package.
This patch extracts these targets into a common kconfig-package
infrastructure, with the goals of:
- aligning the behavior of all kconfig-based packages
- removing code duplication
In order to use this infrastructure, a package should at a minimum specify
FOO_KCONFIG_FILE and eval the kconfig-package macro. The supported
configuration editors can be set with FOO_KCONFIG_EDITORS and defaults to
menuconfig only.
Additionally, a package can specify FOO_KCONFIG_OPT for extra options to
pass to the invocation of the kconfig editors, and FOO_KCONFIG_FIXUP_CMDS
for a list of shell commands used to fixup the .config file after a
configuration has been created/edited.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
[yann.morin.1998@free.fr: add missing 4th argument when calling to
inner-kconfig-package (namely, 'target']
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-08-03 17:32:40 +02:00
|
|
|
$(2)_KCONFIG_FIXUP_CMDS ?=
|
2015-04-28 16:34:31 +02:00
|
|
|
$(2)_KCONFIG_FRAGMENT_FILES ?=
|
2016-09-13 21:45:33 +02:00
|
|
|
$(2)_KCONFIG_DOTCONFIG ?= .config
|
infra: introduce a kconfig-package infrastructure
There are several packages that have a configuration file managed by
kconfig: uclibc, busybox, linux and barebox. All these packages need some
make targets to handle the kconfig specificities: creating a configuration
(menuconfig, ...) and saving it back (update-config, ...)
These targets should be the same for each of these packages, but
unfortunately they are not. Especially with respect to saving back the
configuration to the original config file, there are many differences.
A previous set of patches fixed these targets for the uclibc package.
This patch extracts these targets into a common kconfig-package
infrastructure, with the goals of:
- aligning the behavior of all kconfig-based packages
- removing code duplication
In order to use this infrastructure, a package should at a minimum specify
FOO_KCONFIG_FILE and eval the kconfig-package macro. The supported
configuration editors can be set with FOO_KCONFIG_EDITORS and defaults to
menuconfig only.
Additionally, a package can specify FOO_KCONFIG_OPT for extra options to
pass to the invocation of the kconfig editors, and FOO_KCONFIG_FIXUP_CMDS
for a list of shell commands used to fixup the .config file after a
configuration has been created/edited.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
[yann.morin.1998@free.fr: add missing 4th argument when calling to
inner-kconfig-package (namely, 'target']
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-08-03 17:32:40 +02:00
|
|
|
|
2019-05-30 20:09:09 +02:00
|
|
|
# Do not use $(2)_KCONFIG_DOTCONFIG as stamp file, because the package
|
|
|
|
# buildsystem (e.g. linux >= 4.19) may touch it, thus rendering our
|
|
|
|
# timestamps out of date, thus re-trigerring the build of the package.
|
|
|
|
# Instead, use a specific file of our own as timestamp.
|
|
|
|
$(2)_KCONFIG_STAMP_DOTCONFIG = .stamp_dotconfig
|
|
|
|
|
2015-06-13 18:46:33 +02:00
|
|
|
# The config file as well as the fragments could be in-tree, so before
|
core/pkg-kconfig: ensure kconfig base and fragment files exist
Even though we do have a dependency chain back to each of the kconfig
base and fragment files:
$$($(2)_DIR)/.config: $$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES)
we can't rely on it to ensure they are all present, because they all have
this rule:
$$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES): | $(1)-patch
but since this rule has no prerequisite (only build-order, but that does
not count in this case) and no recipe, make will believe each missing
file to be a PHONY target, and will always run targets that depend on
it:
https://www.gnu.org/software/make/manual/make.html#Force-Targets
So, that means a missing kconfig base or fragment file would always
cause the rule to generate .config to be run at each invocation, which
in turn would cause a rebuild of the kernel, which is clearly not what
we want.
Since this is expected make behaviour, we can well end up with a missing
Kconfig base or fragment. To avoid continuously rebuilding the kernel in
that case, we must check those files exist by ourselves, and error out
if any one of them is missing.
One would expect we check for them right in their dependency rule, like
so:
$$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES): | $(1)-patch
[ -f $(@) ] || {echo Missing $(@) >&2; exit 1; }
but that does not work, as only the first target is tested for. That
check msut be turned into a loop explicitly testing all files, like so:
$$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES): | $(1)-patch
for f in $$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES); do \
[ -f $(@) ] || {echo Missing $$$${f} >&2; exit 1; }; \
done
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Floris Bos <bos@je-eigen-domein.nl>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-06-13 18:46:34 +02:00
|
|
|
# depending on them the package should be extracted (and patched) first.
|
|
|
|
#
|
|
|
|
# Since those files only have a order-only dependency, make would treat
|
|
|
|
# any missing one as a "force" target:
|
|
|
|
# https://www.gnu.org/software/make/manual/make.html#Force-Targets
|
|
|
|
# and would forcibly any rule that depend on those files, causing a
|
|
|
|
# rebuild of the kernel each time make is called.
|
|
|
|
#
|
|
|
|
# So, we provide a recipe that checks all of those files exist, to
|
|
|
|
# overcome that standard make behaviour.
|
|
|
|
#
|
2015-06-13 18:46:33 +02:00
|
|
|
$$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES): | $(1)-patch
|
core/pkg-kconfig: ensure kconfig base and fragment files exist
Even though we do have a dependency chain back to each of the kconfig
base and fragment files:
$$($(2)_DIR)/.config: $$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES)
we can't rely on it to ensure they are all present, because they all have
this rule:
$$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES): | $(1)-patch
but since this rule has no prerequisite (only build-order, but that does
not count in this case) and no recipe, make will believe each missing
file to be a PHONY target, and will always run targets that depend on
it:
https://www.gnu.org/software/make/manual/make.html#Force-Targets
So, that means a missing kconfig base or fragment file would always
cause the rule to generate .config to be run at each invocation, which
in turn would cause a rebuild of the kernel, which is clearly not what
we want.
Since this is expected make behaviour, we can well end up with a missing
Kconfig base or fragment. To avoid continuously rebuilding the kernel in
that case, we must check those files exist by ourselves, and error out
if any one of them is missing.
One would expect we check for them right in their dependency rule, like
so:
$$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES): | $(1)-patch
[ -f $(@) ] || {echo Missing $(@) >&2; exit 1; }
but that does not work, as only the first target is tested for. That
check msut be turned into a loop explicitly testing all files, like so:
$$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES): | $(1)-patch
for f in $$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES); do \
[ -f $(@) ] || {echo Missing $$$${f} >&2; exit 1; }; \
done
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Floris Bos <bos@je-eigen-domein.nl>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-06-13 18:46:34 +02:00
|
|
|
for f in $$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES); do \
|
|
|
|
if [ ! -f "$$$${f}" ]; then \
|
|
|
|
printf "Kconfig fragment '%s' for '%s' does not exist\n" "$$$${f}" "$(1)"; \
|
|
|
|
exit 1; \
|
|
|
|
fi; \
|
|
|
|
done
|
2015-02-03 15:21:41 +01:00
|
|
|
|
2016-04-18 11:23:01 +02:00
|
|
|
$(2)_KCONFIG_MAKE = \
|
2020-08-04 21:00:04 +02:00
|
|
|
$$($(2)_MAKE_ENV) $$($(2)_MAKE) -C $$($(2)_DIR) \
|
package/pkg-kconfig: pass HOSTCC during kconfig steps
The kconfig build logic uses the HOSTCC variable to find the host
compiler. It makes sense to explicitly pass a value to this variable,
pointing to the host compiler used by Buildroot.
During the kconfig step, host-ccache is not ready (host-ccache is only
a dependency to the configure step of packages), so we use
$(HOSTCC_NOCCACHE).
Packages currently using the kconfig-package fell into two categories:
- Those not passing any HOSTCC value. For such packages, it was the
default host compiler detected by the kconfig build logic that was
used. ccache was therefore never used. With this commit, those
packages will now be using the host compiler detected by
Buildroot. Packages in this situation: at91bootstrap3, barebox,
busybox, swupdate, uclibc, xvisor.
- Those passing a HOSTCC value. Such packages were passing $(HOSTCC),
which doesn't work as host-ccache will not be ready. This commit
does not fix them, as they still override HOSTCC. It will be fixed
in followup commits. Packages in this situation: uboot and
linux. Note that linux was a bit special, because it has a
KCONFIG_DEPENDENCIES on the toolchain package, so in fact
host-ccache was ready.
So practically speaking, this commit does not fix anything, as the two
only problematic packages that use $(HOSTCC) are not fixed. However,
it makes things more correct by explicitly telling kconfig which
compiler to use.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-01-10 22:14:58 +01:00
|
|
|
$$(PKG_KCONFIG_COMMON_OPTS) $$($(2)_KCONFIG_OPTS)
|
2016-04-18 11:23:01 +02:00
|
|
|
|
2016-05-02 10:36:39 +02:00
|
|
|
# $(2)_KCONFIG_MAKE may already rely on shell expansion. As the $() syntax
|
|
|
|
# of the shell conflicts with Make's own syntax, this means that backticks
|
|
|
|
# are used with those shell constructs. Unfortunately, the backtick syntax
|
|
|
|
# does not nest, and we need to use Make instead of the shell to handle
|
|
|
|
# conditions.
|
|
|
|
|
|
|
|
# A recursively expanded variable is necessary, to be sure that the shell
|
|
|
|
# command is called when the rule is processed during the build and not
|
|
|
|
# when the rule is created when parsing all packages.
|
|
|
|
$(2)_KCONFIG_RULES = \
|
|
|
|
$$(shell $$($(2)_KCONFIG_MAKE) -pn config 2>/dev/null | \
|
|
|
|
sed 's/^\([_0-9a-zA-Z]*config\):.*/\1/ p; d')
|
|
|
|
|
2015-04-28 16:34:31 +02:00
|
|
|
# The specified source configuration file and any additional configuration file
|
|
|
|
# fragments are merged together to .config, after the package has been patched.
|
2015-02-03 15:21:42 +01:00
|
|
|
# Since the file could be a defconfig file it needs to be expanded to a
|
2016-05-02 10:36:39 +02:00
|
|
|
# full .config first.
|
2019-05-30 20:09:09 +02:00
|
|
|
$$($(2)_DIR)/$$($(2)_KCONFIG_STAMP_DOTCONFIG): $$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES)
|
2019-11-05 17:46:43 +01:00
|
|
|
$$(call prepare-per-package-directory,$$($(2)_KCONFIG_DEPENDENCIES))
|
2018-09-21 15:55:21 +02:00
|
|
|
$$(call kconfig-package-merge-config,$(2),$$(@D)/$$($(2)_KCONFIG_DOTCONFIG),\
|
|
|
|
$$($(2)_KCONFIG_FRAGMENT_FILES))
|
2019-05-30 20:09:09 +02:00
|
|
|
$$(Q)touch $$(@D)/$$($(2)_KCONFIG_STAMP_DOTCONFIG)
|
infra: introduce a kconfig-package infrastructure
There are several packages that have a configuration file managed by
kconfig: uclibc, busybox, linux and barebox. All these packages need some
make targets to handle the kconfig specificities: creating a configuration
(menuconfig, ...) and saving it back (update-config, ...)
These targets should be the same for each of these packages, but
unfortunately they are not. Especially with respect to saving back the
configuration to the original config file, there are many differences.
A previous set of patches fixed these targets for the uclibc package.
This patch extracts these targets into a common kconfig-package
infrastructure, with the goals of:
- aligning the behavior of all kconfig-based packages
- removing code duplication
In order to use this infrastructure, a package should at a minimum specify
FOO_KCONFIG_FILE and eval the kconfig-package macro. The supported
configuration editors can be set with FOO_KCONFIG_EDITORS and defaults to
menuconfig only.
Additionally, a package can specify FOO_KCONFIG_OPT for extra options to
pass to the invocation of the kconfig editors, and FOO_KCONFIG_FIXUP_CMDS
for a list of shell commands used to fixup the .config file after a
configuration has been created/edited.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
[yann.morin.1998@free.fr: add missing 4th argument when calling to
inner-kconfig-package (namely, 'target']
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-08-03 17:32:40 +02:00
|
|
|
|
2016-01-24 23:58:42 +01:00
|
|
|
# If _KCONFIG_FILE or _KCONFIG_FRAGMENT_FILES exists, this dependency is
|
|
|
|
# already implied, but if we only have a _KCONFIG_DEFCONFIG we have to add
|
|
|
|
# it explicitly. It doesn't hurt to always have it though.
|
2019-05-30 20:09:09 +02:00
|
|
|
$$($(2)_DIR)/$$($(2)_KCONFIG_STAMP_DOTCONFIG): | $(1)-patch
|
2016-01-24 23:58:42 +01:00
|
|
|
|
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
|
|
|
# Some packages may need additional tools to be present by the time their
|
|
|
|
# kconfig structure is parsed (e.g. the linux kernel may need to call to
|
|
|
|
# the compiler to test its features).
|
2019-05-30 20:09:09 +02:00
|
|
|
$$($(2)_DIR)/$$($(2)_KCONFIG_STAMP_DOTCONFIG): | $$($(2)_KCONFIG_DEPENDENCIES)
|
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
|
|
|
|
infra: introduce a kconfig-package infrastructure
There are several packages that have a configuration file managed by
kconfig: uclibc, busybox, linux and barebox. All these packages need some
make targets to handle the kconfig specificities: creating a configuration
(menuconfig, ...) and saving it back (update-config, ...)
These targets should be the same for each of these packages, but
unfortunately they are not. Especially with respect to saving back the
configuration to the original config file, there are many differences.
A previous set of patches fixed these targets for the uclibc package.
This patch extracts these targets into a common kconfig-package
infrastructure, with the goals of:
- aligning the behavior of all kconfig-based packages
- removing code duplication
In order to use this infrastructure, a package should at a minimum specify
FOO_KCONFIG_FILE and eval the kconfig-package macro. The supported
configuration editors can be set with FOO_KCONFIG_EDITORS and defaults to
menuconfig only.
Additionally, a package can specify FOO_KCONFIG_OPT for extra options to
pass to the invocation of the kconfig editors, and FOO_KCONFIG_FIXUP_CMDS
for a list of shell commands used to fixup the .config file after a
configuration has been created/edited.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
[yann.morin.1998@free.fr: add missing 4th argument when calling to
inner-kconfig-package (namely, 'target']
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-08-03 17:32:40 +02:00
|
|
|
# In order to get a usable, consistent configuration, some fixup may be needed.
|
|
|
|
# The exact rules are specified by the package .mk file.
|
2015-06-13 18:46:35 +02:00
|
|
|
define $(2)_FIXUP_DOT_CONFIG
|
infra: introduce a kconfig-package infrastructure
There are several packages that have a configuration file managed by
kconfig: uclibc, busybox, linux and barebox. All these packages need some
make targets to handle the kconfig specificities: creating a configuration
(menuconfig, ...) and saving it back (update-config, ...)
These targets should be the same for each of these packages, but
unfortunately they are not. Especially with respect to saving back the
configuration to the original config file, there are many differences.
A previous set of patches fixed these targets for the uclibc package.
This patch extracts these targets into a common kconfig-package
infrastructure, with the goals of:
- aligning the behavior of all kconfig-based packages
- removing code duplication
In order to use this infrastructure, a package should at a minimum specify
FOO_KCONFIG_FILE and eval the kconfig-package macro. The supported
configuration editors can be set with FOO_KCONFIG_EDITORS and defaults to
menuconfig only.
Additionally, a package can specify FOO_KCONFIG_OPT for extra options to
pass to the invocation of the kconfig editors, and FOO_KCONFIG_FIXUP_CMDS
for a list of shell commands used to fixup the .config file after a
configuration has been created/edited.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
[yann.morin.1998@free.fr: add missing 4th argument when calling to
inner-kconfig-package (namely, 'target']
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-08-03 17:32:40 +02:00
|
|
|
$$($(2)_KCONFIG_FIXUP_CMDS)
|
2018-09-21 15:55:20 +02:00
|
|
|
$$(call kconfig-package-regen-dot-config,$(2))
|
2015-06-13 18:46:35 +02:00
|
|
|
$$(Q)touch $$($(2)_DIR)/.stamp_kconfig_fixup_done
|
|
|
|
endef
|
|
|
|
|
package/pkg-utils.mk: kconfig mangling defaults to current package's .config
The kconfig mangling macros currently operate on the caller-supplied
.config file, on the assumption that the caller will always know what
file to mangle.
This was correct so far, as packages would indeed only mangle their
own .config files.
However, the Linux kernel does its mangling based on whether some
other packages are enabled or not. That list of conditional mangling
is getting bigger and bigger with each new package that needs such
mangling, culminating with the pending firewalld one [0]. Furthermore,
this mangling is not accessible to packages in br2-external trees. So
we'll want to have packages provide the mangling commands.
So we'll want the mangling to be done on the Linux' .config file in
the expanding package context, not in the package calling the macros.
But packages do not, and should not have knowledge about where the
.config file is, nor how it is named.
So we make the parameter to specify the .config file to mangle
optional. If it is set, this is what the macros will mangle; if it is
not set, the expanding package's .config file will be used.
This has the added benefit that we do not have to repeat in the
expanding package context the knowledge of how the .config file is
named:
FOO_KCONFIG_DOTCONFIG = .config
define FOO_KCONFIG_FIXUPS_CMDS
$(call KCONFIG_ENABLE_OPT,BLA)
endef
[0] http://lists.busybox.net/pipermail/buildroot/2020-March/278683.html
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-04-04 14:10:14 +02:00
|
|
|
$$($(2)_DIR)/.stamp_kconfig_fixup_done: PKG=$(2)
|
2019-05-30 20:09:09 +02:00
|
|
|
$$($(2)_DIR)/.stamp_kconfig_fixup_done: $$($(2)_DIR)/$$($(2)_KCONFIG_STAMP_DOTCONFIG)
|
2016-04-18 11:23:02 +02:00
|
|
|
$$($(2)_FIXUP_DOT_CONFIG)
|
infra: introduce a kconfig-package infrastructure
There are several packages that have a configuration file managed by
kconfig: uclibc, busybox, linux and barebox. All these packages need some
make targets to handle the kconfig specificities: creating a configuration
(menuconfig, ...) and saving it back (update-config, ...)
These targets should be the same for each of these packages, but
unfortunately they are not. Especially with respect to saving back the
configuration to the original config file, there are many differences.
A previous set of patches fixed these targets for the uclibc package.
This patch extracts these targets into a common kconfig-package
infrastructure, with the goals of:
- aligning the behavior of all kconfig-based packages
- removing code duplication
In order to use this infrastructure, a package should at a minimum specify
FOO_KCONFIG_FILE and eval the kconfig-package macro. The supported
configuration editors can be set with FOO_KCONFIG_EDITORS and defaults to
menuconfig only.
Additionally, a package can specify FOO_KCONFIG_OPT for extra options to
pass to the invocation of the kconfig editors, and FOO_KCONFIG_FIXUP_CMDS
for a list of shell commands used to fixup the .config file after a
configuration has been created/edited.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
[yann.morin.1998@free.fr: add missing 4th argument when calling to
inner-kconfig-package (namely, 'target']
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-08-03 17:32:40 +02:00
|
|
|
|
|
|
|
# Before running configure, the configuration file should be present and fixed
|
|
|
|
$$($(2)_TARGET_CONFIGURE): $$($(2)_DIR)/.stamp_kconfig_fixup_done
|
|
|
|
|
infra/pkg-kconfig: Be sure to reconfigure the package on foo-reconfigure
Currently, calling foo-reconfigure for a kconfig-based package will not
re-trigger the configuration (kconfig-wise) step for the package.
This can be problematic when using an override-srcdir suring development
and the content of the veride-srcdir changes (e.g. on a rebase, a merge,
or during a bisect).
This is because the configuration (kconfig-wise) of the package is not
done in the _CONFIGURE_CMDS block, but as a separate action that is not
part of any step [0].
So, be sure to remove the stamp file .stamp_kconfig_fixup_done during
the foo-clean-for-reconfigure rule, so that the configuration is applied
again with the new source tree.
We use another rule, foo-clean-kconfig-for-reconfigure, because we do
not want to override the default foo-clean-for-reconfigure rule, and we
have no way to add conditional commands to it.
[0] The reasons it was not done are not entirely clear in my head, but
IIRC that was not working at the time we tried with Thomas DS.
Reported-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-14 00:35:17 +02:00
|
|
|
# Force olddefconfig again on -reconfigure
|
|
|
|
$(1)-clean-for-reconfigure: $(1)-clean-kconfig-for-reconfigure
|
|
|
|
|
|
|
|
$(1)-clean-kconfig-for-reconfigure:
|
2019-11-26 14:24:58 +01:00
|
|
|
rm -f $$($(2)_DIR)/$$($(2)_KCONFIG_STAMP_DOTCONFIG)
|
infra/pkg-kconfig: Be sure to reconfigure the package on foo-reconfigure
Currently, calling foo-reconfigure for a kconfig-based package will not
re-trigger the configuration (kconfig-wise) step for the package.
This can be problematic when using an override-srcdir suring development
and the content of the veride-srcdir changes (e.g. on a rebase, a merge,
or during a bisect).
This is because the configuration (kconfig-wise) of the package is not
done in the _CONFIGURE_CMDS block, but as a separate action that is not
part of any step [0].
So, be sure to remove the stamp file .stamp_kconfig_fixup_done during
the foo-clean-for-reconfigure rule, so that the configuration is applied
again with the new source tree.
We use another rule, foo-clean-kconfig-for-reconfigure, because we do
not want to override the default foo-clean-for-reconfigure rule, and we
have no way to add conditional commands to it.
[0] The reasons it was not done are not entirely clear in my head, but
IIRC that was not working at the time we tried with Thomas DS.
Reported-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-14 00:35:17 +02:00
|
|
|
|
2015-02-03 15:21:45 +01:00
|
|
|
# Only enable the foo-*config targets when the package is actually enabled.
|
|
|
|
# Note: the variable $(2)_KCONFIG_VAR is not related to the kconfig
|
|
|
|
# infrastructure, but defined by pkg-generic.mk. The generic infrastructure is
|
|
|
|
# already called above, so we can effectively use this variable.
|
|
|
|
ifeq ($$($$($(2)_KCONFIG_VAR)),y)
|
|
|
|
|
2015-07-13 12:31:58 +02:00
|
|
|
ifeq ($$(BR_BUILDING),y)
|
2015-12-22 22:22:00 +01:00
|
|
|
# Either FOO_KCONFIG_FILE or FOO_KCONFIG_DEFCONFIG is required...
|
|
|
|
ifeq ($$(or $$($(2)_KCONFIG_FILE),$$($(2)_KCONFIG_DEFCONFIG)),)
|
|
|
|
$$(error Internal error: no value specified for $(2)_KCONFIG_FILE or $(2)_KCONFIG_DEFCONFIG)
|
|
|
|
endif
|
|
|
|
# ... but not both:
|
|
|
|
ifneq ($$(and $$($(2)_KCONFIG_FILE),$$($(2)_KCONFIG_DEFCONFIG)),)
|
|
|
|
$$(error Internal error: $(2)_KCONFIG_FILE and $(2)_KCONFIG_DEFCONFIG are mutually exclusive but both are defined)
|
2015-04-08 19:08:34 +02:00
|
|
|
endif
|
2015-07-13 12:31:58 +02:00
|
|
|
endif
|
2015-04-08 19:08:34 +02:00
|
|
|
|
core/pkg-kconfig: fix configurators
Currently, the configurators are using $($(2)_MAKE_ENV), often derived
from $(TARGE_MAKE_ENV), as the environment to be set when calling the
various configurators.
This means that our host tools are used first, most notably pkg-config
(from host-pkgconf).
However, this is inherently flawed. Our pkg-config, when set for the
host, only searches .pc files in $(HOST_DIR) and never ever uses the
ones from the host. For example, since we do not build a host-qt, our
pkg-config would not find the host's QtCore.pc et al.
Consequently, on some systems (but not on others?) most of the
configurators fail to build, especially the latest kernel versions, as
they have been starting to use pkg-config two years ago.
Fix that by filtering-out sensible values out of the environment, but
only when calling the configurators.
[Thomas: rewrap comment to appropriate length.]
Reported-by: Mauro Condarelli <mc5686@mclink.it>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Mauro Condarelli <mc5686@mclink.it>
Tested-by: Mauro Condarelli <mc5686@mclink.it>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-08-22 19:53:13 +02:00
|
|
|
# For the configurators, we do want to use the system-provided host
|
|
|
|
# tools, not the ones we build. This is particularly true for
|
|
|
|
# pkg-config; if we use our pkg-config (from host-pkgconf), then it
|
|
|
|
# would not look for the .pc from the host, but we do need them,
|
|
|
|
# especially to find ncurses, GTK+, Qt (resp. for menuconfig and
|
|
|
|
# nconfig, gconfig, xconfig).
|
|
|
|
# So we simply remove our PATH and PKG_CONFIG_* variables.
|
|
|
|
$(2)_CONFIGURATOR_MAKE_ENV = \
|
2019-04-08 20:42:33 +02:00
|
|
|
$$(filter-out PATH=% PKG_CONFIG=% PKG_CONFIG_SYSROOT_DIR=% \
|
|
|
|
PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=% PKG_CONFIG_ALLOW_SYSTEM_LIBS=% \
|
|
|
|
PKG_CONFIG_LIBDIR=%,$$($(2)_MAKE_ENV)) \
|
2016-05-28 00:03:28 +02:00
|
|
|
PKG_CONFIG_PATH="$(HOST_PKG_CONFIG_PATH)"
|
core/pkg-kconfig: fix configurators
Currently, the configurators are using $($(2)_MAKE_ENV), often derived
from $(TARGE_MAKE_ENV), as the environment to be set when calling the
various configurators.
This means that our host tools are used first, most notably pkg-config
(from host-pkgconf).
However, this is inherently flawed. Our pkg-config, when set for the
host, only searches .pc files in $(HOST_DIR) and never ever uses the
ones from the host. For example, since we do not build a host-qt, our
pkg-config would not find the host's QtCore.pc et al.
Consequently, on some systems (but not on others?) most of the
configurators fail to build, especially the latest kernel versions, as
they have been starting to use pkg-config two years ago.
Fix that by filtering-out sensible values out of the environment, but
only when calling the configurators.
[Thomas: rewrap comment to appropriate length.]
Reported-by: Mauro Condarelli <mc5686@mclink.it>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Mauro Condarelli <mc5686@mclink.it>
Tested-by: Mauro Condarelli <mc5686@mclink.it>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-08-22 19:53:13 +02:00
|
|
|
|
infra: introduce a kconfig-package infrastructure
There are several packages that have a configuration file managed by
kconfig: uclibc, busybox, linux and barebox. All these packages need some
make targets to handle the kconfig specificities: creating a configuration
(menuconfig, ...) and saving it back (update-config, ...)
These targets should be the same for each of these packages, but
unfortunately they are not. Especially with respect to saving back the
configuration to the original config file, there are many differences.
A previous set of patches fixed these targets for the uclibc package.
This patch extracts these targets into a common kconfig-package
infrastructure, with the goals of:
- aligning the behavior of all kconfig-based packages
- removing code duplication
In order to use this infrastructure, a package should at a minimum specify
FOO_KCONFIG_FILE and eval the kconfig-package macro. The supported
configuration editors can be set with FOO_KCONFIG_EDITORS and defaults to
menuconfig only.
Additionally, a package can specify FOO_KCONFIG_OPT for extra options to
pass to the invocation of the kconfig editors, and FOO_KCONFIG_FIXUP_CMDS
for a list of shell commands used to fixup the .config file after a
configuration has been created/edited.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
[yann.morin.1998@free.fr: add missing 4th argument when calling to
inner-kconfig-package (namely, 'target']
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-08-03 17:32:40 +02:00
|
|
|
# Configuration editors (menuconfig, ...)
|
2015-06-13 18:46:36 +02:00
|
|
|
#
|
core/pkg-kconfig: allow saving config to a non-existing custom config file
A very interesting use-case for a kconfig-based package is to create a
custom (def)config file based on one bundled with the package itself,
like described in PR-8156:
make menuconfig
-> enable kernel, use an in-tree defconfig, save and exit
make linux-menuconfig
-> enable/disable whatever option, save and exit
make menuconfig
-> change to use a custom defconfig file, set a path, save and exit
make linux-update-config
-> should save to the new custom defconfig file
However, that is currently not possible, because the dependency chain
when saving the configuration goes back up to the (newly-set!) custom
(def)config file, which does not exist.
So, we break the dependency chain so that saving the configuration does
not depend on that file. Instead, we use a terminal rule that checks
that the configuration has indeed been done, and fails if not.
Closes #8156.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-06-13 18:46:37 +02:00
|
|
|
# We need to apply the configuration fixups right after a configuration
|
|
|
|
# editor exits, so that it is possible to save the configuration right
|
|
|
|
# after exiting an editor, and so the user always sees a .config file
|
|
|
|
# that is clean wrt. our requirements.
|
2015-06-13 18:46:36 +02:00
|
|
|
#
|
|
|
|
# Because commands in $(1)_FIXUP_KCONFIG are probably using $(@D), we
|
core/pkg-kconfig: do not override @D
Currently, we override @D for the kconfig configurators, so the fixup
commands can use $(@D); otherwise @D would be simply '.' because it is
not a real file in the package build dir.
However, this breaks the soon-to-be-introduced linux-backports package,
which needs to have a dependency on the linux package to be configured.
The underlying reason is that @D is an automatic variable that is always
set by make to the directory part of the target of the rule. However,
automatic variables loose their "automatic" property when they are
manually set.
Furthermore, a variable that is defined for a rule is inherited by all
dependencies of that rule, so our manually-set @D is inherited all the
way down the dependency chain of linux-backports, down to the linux' own
.config rule, which is thus run with @D pointing to linux-backports'
build dir, not linux'.
Fix that by using a "static pattern rule", redirecting the configurators
to an intermediate stamp-like file which path is in the package build
dir, so we get a valid @D from the onset, without having to manually
fiddle with it.
Thanks to Arnout for suggesting that in the first place. Sorry I did
reject it as "too complex" when it was in fact the best solution.
Suggested-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-22 16:58:52 +02:00
|
|
|
# need to have a valid @D set. But, because the configurators rules are
|
|
|
|
# not real files and do not contain the path to the package build dir,
|
|
|
|
# @D would be just '.' in this case. So, we use an intermediate rule
|
|
|
|
# with a stamp-like file which path is in the package build dir, so we
|
|
|
|
# end up having a valid @D.
|
2015-06-13 18:46:36 +02:00
|
|
|
#
|
core/pkg-kconfig: do not override @D
Currently, we override @D for the kconfig configurators, so the fixup
commands can use $(@D); otherwise @D would be simply '.' because it is
not a real file in the package build dir.
However, this breaks the soon-to-be-introduced linux-backports package,
which needs to have a dependency on the linux package to be configured.
The underlying reason is that @D is an automatic variable that is always
set by make to the directory part of the target of the rule. However,
automatic variables loose their "automatic" property when they are
manually set.
Furthermore, a variable that is defined for a rule is inherited by all
dependencies of that rule, so our manually-set @D is inherited all the
way down the dependency chain of linux-backports, down to the linux' own
.config rule, which is thus run with @D pointing to linux-backports'
build dir, not linux'.
Fix that by using a "static pattern rule", redirecting the configurators
to an intermediate stamp-like file which path is in the package build
dir, so we get a valid @D from the onset, without having to manually
fiddle with it.
Thanks to Arnout for suggesting that in the first place. Sorry I did
reject it as "too complex" when it was in fact the best solution.
Suggested-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-22 16:58:52 +02:00
|
|
|
$$(addprefix $(1)-,$$($(2)_KCONFIG_EDITORS)): $(1)-%: $$($(2)_DIR)/.kconfig_editor_%
|
package/pkg-utils.mk: kconfig mangling defaults to current package's .config
The kconfig mangling macros currently operate on the caller-supplied
.config file, on the assumption that the caller will always know what
file to mangle.
This was correct so far, as packages would indeed only mangle their
own .config files.
However, the Linux kernel does its mangling based on whether some
other packages are enabled or not. That list of conditional mangling
is getting bigger and bigger with each new package that needs such
mangling, culminating with the pending firewalld one [0]. Furthermore,
this mangling is not accessible to packages in br2-external trees. So
we'll want to have packages provide the mangling commands.
So we'll want the mangling to be done on the Linux' .config file in
the expanding package context, not in the package calling the macros.
But packages do not, and should not have knowledge about where the
.config file is, nor how it is named.
So we make the parameter to specify the .config file to mangle
optional. If it is set, this is what the macros will mangle; if it is
not set, the expanding package's .config file will be used.
This has the added benefit that we do not have to repeat in the
expanding package context the knowledge of how the .config file is
named:
FOO_KCONFIG_DOTCONFIG = .config
define FOO_KCONFIG_FIXUPS_CMDS
$(call KCONFIG_ENABLE_OPT,BLA)
endef
[0] http://lists.busybox.net/pipermail/buildroot/2020-March/278683.html
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-04-04 14:10:14 +02:00
|
|
|
$$($(2)_DIR)/.kconfig_editor_%: PKG=$(2)
|
core/pkg-kconfig: do not override @D
Currently, we override @D for the kconfig configurators, so the fixup
commands can use $(@D); otherwise @D would be simply '.' because it is
not a real file in the package build dir.
However, this breaks the soon-to-be-introduced linux-backports package,
which needs to have a dependency on the linux package to be configured.
The underlying reason is that @D is an automatic variable that is always
set by make to the directory part of the target of the rule. However,
automatic variables loose their "automatic" property when they are
manually set.
Furthermore, a variable that is defined for a rule is inherited by all
dependencies of that rule, so our manually-set @D is inherited all the
way down the dependency chain of linux-backports, down to the linux' own
.config rule, which is thus run with @D pointing to linux-backports'
build dir, not linux'.
Fix that by using a "static pattern rule", redirecting the configurators
to an intermediate stamp-like file which path is in the package build
dir, so we get a valid @D from the onset, without having to manually
fiddle with it.
Thanks to Arnout for suggesting that in the first place. Sorry I did
reject it as "too complex" when it was in fact the best solution.
Suggested-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-22 16:58:52 +02:00
|
|
|
$$($(2)_DIR)/.kconfig_editor_%: $$($(2)_DIR)/.stamp_kconfig_fixup_done
|
2020-08-04 21:00:04 +02:00
|
|
|
$$($(2)_CONFIGURATOR_MAKE_ENV) $$($(2)_MAKE) -C $$($(2)_DIR) \
|
package/pkg-kconfig: pass HOSTCC during kconfig steps
The kconfig build logic uses the HOSTCC variable to find the host
compiler. It makes sense to explicitly pass a value to this variable,
pointing to the host compiler used by Buildroot.
During the kconfig step, host-ccache is not ready (host-ccache is only
a dependency to the configure step of packages), so we use
$(HOSTCC_NOCCACHE).
Packages currently using the kconfig-package fell into two categories:
- Those not passing any HOSTCC value. For such packages, it was the
default host compiler detected by the kconfig build logic that was
used. ccache was therefore never used. With this commit, those
packages will now be using the host compiler detected by
Buildroot. Packages in this situation: at91bootstrap3, barebox,
busybox, swupdate, uclibc, xvisor.
- Those passing a HOSTCC value. Such packages were passing $(HOSTCC),
which doesn't work as host-ccache will not be ready. This commit
does not fix them, as they still override HOSTCC. It will be fixed
in followup commits. Packages in this situation: uboot and
linux. Note that linux was a bit special, because it has a
KCONFIG_DEPENDENCIES on the toolchain package, so in fact
host-ccache was ready.
So practically speaking, this commit does not fix anything, as the two
only problematic packages that use $(HOSTCC) are not fixed. However,
it makes things more correct by explicitly telling kconfig which
compiler to use.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-01-10 22:14:58 +01:00
|
|
|
$$(PKG_KCONFIG_COMMON_OPTS) $$($(2)_KCONFIG_OPTS) $$(*)
|
infra: introduce a kconfig-package infrastructure
There are several packages that have a configuration file managed by
kconfig: uclibc, busybox, linux and barebox. All these packages need some
make targets to handle the kconfig specificities: creating a configuration
(menuconfig, ...) and saving it back (update-config, ...)
These targets should be the same for each of these packages, but
unfortunately they are not. Especially with respect to saving back the
configuration to the original config file, there are many differences.
A previous set of patches fixed these targets for the uclibc package.
This patch extracts these targets into a common kconfig-package
infrastructure, with the goals of:
- aligning the behavior of all kconfig-based packages
- removing code duplication
In order to use this infrastructure, a package should at a minimum specify
FOO_KCONFIG_FILE and eval the kconfig-package macro. The supported
configuration editors can be set with FOO_KCONFIG_EDITORS and defaults to
menuconfig only.
Additionally, a package can specify FOO_KCONFIG_OPT for extra options to
pass to the invocation of the kconfig editors, and FOO_KCONFIG_FIXUP_CMDS
for a list of shell commands used to fixup the .config file after a
configuration has been created/edited.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
[yann.morin.1998@free.fr: add missing 4th argument when calling to
inner-kconfig-package (namely, 'target']
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-08-03 17:32:40 +02:00
|
|
|
rm -f $$($(2)_DIR)/.stamp_{kconfig_fixup_done,configured,built}
|
2015-02-03 15:21:44 +01:00
|
|
|
rm -f $$($(2)_DIR)/.stamp_{target,staging,images}_installed
|
2016-04-18 11:23:02 +02:00
|
|
|
$$($(2)_FIXUP_DOT_CONFIG)
|
infra: introduce a kconfig-package infrastructure
There are several packages that have a configuration file managed by
kconfig: uclibc, busybox, linux and barebox. All these packages need some
make targets to handle the kconfig specificities: creating a configuration
(menuconfig, ...) and saving it back (update-config, ...)
These targets should be the same for each of these packages, but
unfortunately they are not. Especially with respect to saving back the
configuration to the original config file, there are many differences.
A previous set of patches fixed these targets for the uclibc package.
This patch extracts these targets into a common kconfig-package
infrastructure, with the goals of:
- aligning the behavior of all kconfig-based packages
- removing code duplication
In order to use this infrastructure, a package should at a minimum specify
FOO_KCONFIG_FILE and eval the kconfig-package macro. The supported
configuration editors can be set with FOO_KCONFIG_EDITORS and defaults to
menuconfig only.
Additionally, a package can specify FOO_KCONFIG_OPT for extra options to
pass to the invocation of the kconfig editors, and FOO_KCONFIG_FIXUP_CMDS
for a list of shell commands used to fixup the .config file after a
configuration has been created/edited.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
[yann.morin.1998@free.fr: add missing 4th argument when calling to
inner-kconfig-package (namely, 'target']
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-08-03 17:32:40 +02:00
|
|
|
|
core/pkg-kconfig: allow saving config to a non-existing custom config file
A very interesting use-case for a kconfig-based package is to create a
custom (def)config file based on one bundled with the package itself,
like described in PR-8156:
make menuconfig
-> enable kernel, use an in-tree defconfig, save and exit
make linux-menuconfig
-> enable/disable whatever option, save and exit
make menuconfig
-> change to use a custom defconfig file, set a path, save and exit
make linux-update-config
-> should save to the new custom defconfig file
However, that is currently not possible, because the dependency chain
when saving the configuration goes back up to the (newly-set!) custom
(def)config file, which does not exist.
So, we break the dependency chain so that saving the configuration does
not depend on that file. Instead, we use a terminal rule that checks
that the configuration has indeed been done, and fails if not.
Closes #8156.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-06-13 18:46:37 +02:00
|
|
|
# Saving back the configuration
|
|
|
|
#
|
|
|
|
# Ideally, that should directly depend on $$($(2)_DIR)/.stamp_kconfig_fixup_done,
|
|
|
|
# but that breaks the use-case in PR-8156 (from a clean tree):
|
|
|
|
# make menuconfig <- enable kernel, use an in-tree defconfig, save and exit
|
|
|
|
# make linux-menuconfig <- enable/disable whatever option, save and exit
|
|
|
|
# make menuconfig <- change to use a custom defconfig file, set a path, save and exit
|
|
|
|
# make linux-update-config <- should save to the new custom defconfig file
|
|
|
|
#
|
|
|
|
# Because of that use-case, saving the configuration can *not* directly
|
|
|
|
# depend on the stamp file, because it itself depends on the .config,
|
|
|
|
# which in turn depends on the (newly-set an non-existent) custom
|
|
|
|
# defconfig file.
|
|
|
|
#
|
2017-07-28 01:02:27 +02:00
|
|
|
# Instead, we use a PHONY rule that will catch that situation.
|
core/pkg-kconfig: allow saving config to a non-existing custom config file
A very interesting use-case for a kconfig-based package is to create a
custom (def)config file based on one bundled with the package itself,
like described in PR-8156:
make menuconfig
-> enable kernel, use an in-tree defconfig, save and exit
make linux-menuconfig
-> enable/disable whatever option, save and exit
make menuconfig
-> change to use a custom defconfig file, set a path, save and exit
make linux-update-config
-> should save to the new custom defconfig file
However, that is currently not possible, because the dependency chain
when saving the configuration goes back up to the (newly-set!) custom
(def)config file, which does not exist.
So, we break the dependency chain so that saving the configuration does
not depend on that file. Instead, we use a terminal rule that checks
that the configuration has indeed been done, and fails if not.
Closes #8156.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-06-13 18:46:37 +02:00
|
|
|
#
|
|
|
|
$(1)-check-configuration-done:
|
|
|
|
@if [ ! -f $$($(2)_DIR)/.stamp_kconfig_fixup_done ]; then \
|
|
|
|
echo "$(1) is not yet configured"; \
|
|
|
|
exit 1; \
|
|
|
|
fi
|
|
|
|
|
|
|
|
$(1)-savedefconfig: $(1)-check-configuration-done
|
2018-09-21 15:55:20 +02:00
|
|
|
$$(call kconfig-package-savedefconfig,$(2))
|
2015-02-03 15:21:42 +01:00
|
|
|
|
infra: introduce a kconfig-package infrastructure
There are several packages that have a configuration file managed by
kconfig: uclibc, busybox, linux and barebox. All these packages need some
make targets to handle the kconfig specificities: creating a configuration
(menuconfig, ...) and saving it back (update-config, ...)
These targets should be the same for each of these packages, but
unfortunately they are not. Especially with respect to saving back the
configuration to the original config file, there are many differences.
A previous set of patches fixed these targets for the uclibc package.
This patch extracts these targets into a common kconfig-package
infrastructure, with the goals of:
- aligning the behavior of all kconfig-based packages
- removing code duplication
In order to use this infrastructure, a package should at a minimum specify
FOO_KCONFIG_FILE and eval the kconfig-package macro. The supported
configuration editors can be set with FOO_KCONFIG_EDITORS and defaults to
menuconfig only.
Additionally, a package can specify FOO_KCONFIG_OPT for extra options to
pass to the invocation of the kconfig editors, and FOO_KCONFIG_FIXUP_CMDS
for a list of shell commands used to fixup the .config file after a
configuration has been created/edited.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
[yann.morin.1998@free.fr: add missing 4th argument when calling to
inner-kconfig-package (namely, 'target']
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-08-03 17:32:40 +02:00
|
|
|
# Target to copy back the configuration to the source configuration file
|
2015-02-03 15:21:43 +01:00
|
|
|
# Even though we could use 'cp --preserve-timestamps' here, the separate
|
|
|
|
# cp and 'touch --reference' is used for symmetry with $(1)-update-defconfig.
|
2017-12-01 16:09:44 +01:00
|
|
|
$(1)-update-config: PKG=$(2)
|
core/pkg-kconfig: allow saving config to a non-existing custom config file
A very interesting use-case for a kconfig-based package is to create a
custom (def)config file based on one bundled with the package itself,
like described in PR-8156:
make menuconfig
-> enable kernel, use an in-tree defconfig, save and exit
make linux-menuconfig
-> enable/disable whatever option, save and exit
make menuconfig
-> change to use a custom defconfig file, set a path, save and exit
make linux-update-config
-> should save to the new custom defconfig file
However, that is currently not possible, because the dependency chain
when saving the configuration goes back up to the (newly-set!) custom
(def)config file, which does not exist.
So, we break the dependency chain so that saving the configuration does
not depend on that file. Instead, we use a terminal rule that checks
that the configuration has indeed been done, and fails if not.
Closes #8156.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-06-13 18:46:37 +02:00
|
|
|
$(1)-update-config: $(1)-check-configuration-done
|
2017-12-01 16:09:44 +01:00
|
|
|
$$(call kconfig-package-update-config,$$($(2)_KCONFIG_DOTCONFIG))
|
infra: introduce a kconfig-package infrastructure
There are several packages that have a configuration file managed by
kconfig: uclibc, busybox, linux and barebox. All these packages need some
make targets to handle the kconfig specificities: creating a configuration
(menuconfig, ...) and saving it back (update-config, ...)
These targets should be the same for each of these packages, but
unfortunately they are not. Especially with respect to saving back the
configuration to the original config file, there are many differences.
A previous set of patches fixed these targets for the uclibc package.
This patch extracts these targets into a common kconfig-package
infrastructure, with the goals of:
- aligning the behavior of all kconfig-based packages
- removing code duplication
In order to use this infrastructure, a package should at a minimum specify
FOO_KCONFIG_FILE and eval the kconfig-package macro. The supported
configuration editors can be set with FOO_KCONFIG_EDITORS and defaults to
menuconfig only.
Additionally, a package can specify FOO_KCONFIG_OPT for extra options to
pass to the invocation of the kconfig editors, and FOO_KCONFIG_FIXUP_CMDS
for a list of shell commands used to fixup the .config file after a
configuration has been created/edited.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
[yann.morin.1998@free.fr: add missing 4th argument when calling to
inner-kconfig-package (namely, 'target']
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-08-03 17:32:40 +02:00
|
|
|
|
2015-02-03 15:21:42 +01:00
|
|
|
# Note: make sure the timestamp of the stored configuration is not newer than
|
|
|
|
# the .config to avoid a useless rebuild. Note that, contrary to
|
|
|
|
# $(1)-update-config, the reference for 'touch' is _not_ the file from which
|
|
|
|
# we copy.
|
2017-12-01 16:09:44 +01:00
|
|
|
$(1)-update-defconfig: PKG=$(2)
|
2015-02-03 15:21:42 +01:00
|
|
|
$(1)-update-defconfig: $(1)-savedefconfig
|
2017-12-01 16:09:44 +01:00
|
|
|
$$(call kconfig-package-update-config,defconfig)
|
2015-02-03 15:21:42 +01:00
|
|
|
|
2018-09-21 15:55:21 +02:00
|
|
|
# Target to output differences between the configuration obtained via the
|
|
|
|
# defconfig + fragments (if any) and the current configuration.
|
|
|
|
# Note: it preserves the timestamp of the current configuration when moving it
|
|
|
|
# around.
|
|
|
|
$(1)-diff-config: $(1)-check-configuration-done
|
|
|
|
$$(Q)cp -a $$($(2)_DIR)/$$($(2)_KCONFIG_DOTCONFIG) $$($(2)_DIR)/.config.dc.bak
|
|
|
|
$$(call kconfig-package-merge-config,$(2),$$($(2)_DIR)/$$($(2)_KCONFIG_DOTCONFIG),\
|
|
|
|
$$($(2)_KCONFIG_FRAGMENT_FILES))
|
|
|
|
$$(Q)utils/diffconfig $$($(2)_DIR)/$$($(2)_KCONFIG_DOTCONFIG) \
|
|
|
|
$$($(2)_DIR)/.config.dc.bak
|
|
|
|
$$(Q)cp -a $$($(2)_DIR)/.config.dc.bak $$($(2)_DIR)/$$($(2)_KCONFIG_DOTCONFIG)
|
|
|
|
$$(Q)rm -f $$($(2)_DIR)/.config.dc.bak
|
|
|
|
|
|
|
|
|
2015-02-03 15:21:45 +01:00
|
|
|
endif # package enabled
|
|
|
|
|
2015-04-12 18:37:45 +02:00
|
|
|
.PHONY: \
|
|
|
|
$(1)-update-config \
|
|
|
|
$(1)-update-defconfig \
|
2018-09-21 15:55:21 +02:00
|
|
|
$(1)-diff-config \
|
2015-04-12 18:37:45 +02:00
|
|
|
$(1)-savedefconfig \
|
core/pkg-kconfig: allow saving config to a non-existing custom config file
A very interesting use-case for a kconfig-based package is to create a
custom (def)config file based on one bundled with the package itself,
like described in PR-8156:
make menuconfig
-> enable kernel, use an in-tree defconfig, save and exit
make linux-menuconfig
-> enable/disable whatever option, save and exit
make menuconfig
-> change to use a custom defconfig file, set a path, save and exit
make linux-update-config
-> should save to the new custom defconfig file
However, that is currently not possible, because the dependency chain
when saving the configuration goes back up to the (newly-set!) custom
(def)config file, which does not exist.
So, we break the dependency chain so that saving the configuration does
not depend on that file. Instead, we use a terminal rule that checks
that the configuration has indeed been done, and fails if not.
Closes #8156.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-06-13 18:46:37 +02:00
|
|
|
$(1)-check-configuration-done \
|
core/pkg-kconfig: do not override @D
Currently, we override @D for the kconfig configurators, so the fixup
commands can use $(@D); otherwise @D would be simply '.' because it is
not a real file in the package build dir.
However, this breaks the soon-to-be-introduced linux-backports package,
which needs to have a dependency on the linux package to be configured.
The underlying reason is that @D is an automatic variable that is always
set by make to the directory part of the target of the rule. However,
automatic variables loose their "automatic" property when they are
manually set.
Furthermore, a variable that is defined for a rule is inherited by all
dependencies of that rule, so our manually-set @D is inherited all the
way down the dependency chain of linux-backports, down to the linux' own
.config rule, which is thus run with @D pointing to linux-backports'
build dir, not linux'.
Fix that by using a "static pattern rule", redirecting the configurators
to an intermediate stamp-like file which path is in the package build
dir, so we get a valid @D from the onset, without having to manually
fiddle with it.
Thanks to Arnout for suggesting that in the first place. Sorry I did
reject it as "too complex" when it was in fact the best solution.
Suggested-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-22 16:58:52 +02:00
|
|
|
$$($(2)_DIR)/.kconfig_editor_% \
|
2015-04-12 18:37:45 +02:00
|
|
|
$$(addprefix $(1)-,$$($(2)_KCONFIG_EDITORS))
|
|
|
|
|
infra: introduce a kconfig-package infrastructure
There are several packages that have a configuration file managed by
kconfig: uclibc, busybox, linux and barebox. All these packages need some
make targets to handle the kconfig specificities: creating a configuration
(menuconfig, ...) and saving it back (update-config, ...)
These targets should be the same for each of these packages, but
unfortunately they are not. Especially with respect to saving back the
configuration to the original config file, there are many differences.
A previous set of patches fixed these targets for the uclibc package.
This patch extracts these targets into a common kconfig-package
infrastructure, with the goals of:
- aligning the behavior of all kconfig-based packages
- removing code duplication
In order to use this infrastructure, a package should at a minimum specify
FOO_KCONFIG_FILE and eval the kconfig-package macro. The supported
configuration editors can be set with FOO_KCONFIG_EDITORS and defaults to
menuconfig only.
Additionally, a package can specify FOO_KCONFIG_OPT for extra options to
pass to the invocation of the kconfig editors, and FOO_KCONFIG_FIXUP_CMDS
for a list of shell commands used to fixup the .config file after a
configuration has been created/edited.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
[yann.morin.1998@free.fr: add missing 4th argument when calling to
inner-kconfig-package (namely, 'target']
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-08-03 17:32:40 +02:00
|
|
|
endef # inner-kconfig-package
|
|
|
|
|
|
|
|
################################################################################
|
|
|
|
# kconfig-package -- the target generator macro for kconfig packages
|
|
|
|
################################################################################
|
|
|
|
|
|
|
|
kconfig-package = $(call inner-kconfig-package,$(pkgname),$(call UPPERCASE,$(pkgname)),$(call UPPERCASE,$(pkgname)),target)
|