Fix selection of bootloaders from $(BR2_EXTERNAL)
PATCH v2 1/1 Fix selection of bootloaders from $(BR2_EXTERNAL)
If a package is based on "generic-package", pkg-generic.mk will compute the name of the Kconfig variable to use for checking if this package has been selected by the user.
Unfortunately, this mechanism does not take into account the case where a bootloader is declared in a $(BR2_EXTERNAL)/boot directory.
So, even if the bootloader has been selected, it will not be added to $(TARGETS) and will not be built.
This patch fixes this issue, as well as handle toolchains.
Changes v1 -> v2:
- use multiple patterns in filter (suggested by ThomasDS).
- handle toolchains.
--- package/pkg-generic.mk | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
package/pkg-generic.mk +2 -2
@@ -614,9 +614,9 @@ $$($(2)_TARGET_DIRCLEAN): PKG=$(2) # kernel case, the bootloaders case, and the normal packages case. ifeq ($(1),linux) $(2)_KCONFIG_VAR = BR2_LINUX_KERNEL -else ifneq ($$(filter boot/%,$(pkgdir)),) +else ifneq ($$(filter boot/% $(BR2_EXTERNAL)/boot/%,$(pkgdir)),) $(2)_KCONFIG_VAR = BR2_TARGET_$(2) -else ifneq ($$(filter toolchain/%,$(pkgdir)),) +else ifneq ($$(filter toolchain/% $(BR2_EXTERNAL)/toolchain/%,$(pkgdir)),) $(2)_KCONFIG_VAR = BR2_$(2) else $(2)_KCONFIG_VAR = BR2_PACKAGE_$(2)
--
1.9.1
PATCH v2 1/1 Fix selection of bootloaders from $(BR2_EXTERNAL)
Dear Eric Le Bihan,
Quoted 28 lines · Eric Le Bihan
If a package is based on "generic-package", pkg-generic.mk will compute the name of the
Kconfigvariable to use for checking if this package has been selected by the user.Unfortunately, this mechanism does not take into account the case where a bootloader is declared in a $(BR2_EXTERNAL)/boot directory.
So, even if the bootloader has been selected, it will not be added to $(TARGETS) and will not be built.
This patch fixes this issue, as well as handle toolchains.
Changes v1 -> v2:
- use multiple patterns in filter (suggested by ThomasDS).
- handle toolchains.Signed-off-by Eric Le Bihan <[email protected]>--- package/pkg-generic.mk | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)package/pkg-generic.mk +0
-0@@ -614,9 +614,9 @@ $$($(2)_TARGET_DIRCLEAN): PKG=$(2) # kernel case, the bootloaders case, and the normal packages case.
package/pkg-generic.mk $$($(2)_TARGET_DIRCLEAN): PKG=$(2) · line 622
Quoted 10 lines
package/pkg-generic.mk +2
-2ifeq ($(1),linux) $(2)_KCONFIG_VAR = BR2_LINUX_KERNEL -else ifneq ($$(filter boot/%,$(pkgdir)),) +else ifneq ($$(filter boot/% $(BR2_EXTERNAL)/boot/%,$(pkgdir)),) $(2)_KCONFIG_VAR = BR2_TARGET_$(2) -else ifneq ($$(filter toolchain/%,$(pkgdir)),) +else ifneq ($$(filter toolchain/% $(BR2_EXTERNAL)/toolchain/%,$(pkgdir)),) $(2)_KCONFIG_VAR = BR2_$(2) else $(2)_KCONFIG_VAR = BR2_PACKAGE_$(2)
Well, this makes the assumption that $(BR2_EXTERNAL) bootloaders should be in boot/ and $(BR2_EXTERNAL) toolchain stuff should be in toolchain/.
In practice, the boot/ and toolchain/ organization in the main Buildroot does not necessarily need to be reflected in $(BR2_EXTERNAL):
you can have a bootloader in $(BR2_EXTERNAL)/package/foobar/, just name its option BR2_PACKAGE_FOOBAR and not BR2_TARGET_FOOBAR.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH v2 1/1 Fix selection of bootloaders from $(BR2_EXTERNAL)
Thomas, All
Quoted 45 lines · Thomas Petazzoni
Dear Eric Le Bihan,
Quoted 28 lines · Eric Le Bihan
If a package is based on "generic-package", pkg-generic.mk will compute the name of the
Kconfigvariable to use for checking if this package has been selected by the user.Unfortunately, this mechanism does not take into account the case where a bootloader is declared in a $(BR2_EXTERNAL)/boot directory.
So, even if the bootloader has been selected, it will not be added to $(TARGETS) and will not be built.
This patch fixes this issue, as well as handle toolchains.
Changes v1 -> v2:
- use multiple patterns in filter (suggested by ThomasDS).
- handle toolchains.Signed-off-by Eric Le Bihan <[email protected]>--- package/pkg-generic.mk | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)package/pkg-generic.mk +0
-0@@ -614,9 +614,9 @@ $$($(2)_TARGET_DIRCLEAN): PKG=$(2) # kernel case, the bootloaders case, and the normal packages case.package/pkg-generic.mk $$($(2)_TARGET_DIRCLEAN): PKG=$(2) · line 622
Quoted 10 lines
package/pkg-generic.mk +2
-2ifeq ($(1),linux) $(2)_KCONFIG_VAR = BR2_LINUX_KERNEL -else ifneq ($$(filter boot/%,$(pkgdir)),) +else ifneq ($$(filter boot/% $(BR2_EXTERNAL)/boot/%,$(pkgdir)),) $(2)_KCONFIG_VAR = BR2_TARGET_$(2) -else ifneq ($$(filter toolchain/%,$(pkgdir)),) +else ifneq ($$(filter toolchain/% $(BR2_EXTERNAL)/toolchain/%,$(pkgdir)),) $(2)_KCONFIG_VAR = BR2_$(2) else $(2)_KCONFIG_VAR = BR2_PACKAGE_$(2)Well, this makes the assumption that $(BR2_EXTERNAL) bootloaders should be in boot/ and $(BR2_EXTERNAL) toolchain stuff should be in toolchain/.
Quoted 4 lines
In practice, the boot/ and toolchain/ organization in the main Buildroot does not necessarily need to be reflected in $(BR2_EXTERNAL):
you can have a bootloader in $(BR2_EXTERNAL)/package/foobar/, just name its optionBR2_PACKAGE_FOOBARand notBR2_TARGET_FOOBAR.
On the contrary, I find it confusing *not* to reflect the main Buildroot organization in $(BR2_EXTERNAL).
To me, the $(BR2_EXTERNAL)/package directory should contain Makefiles for programs to be deployed in the rootfs of the target or host tools to build them. But a bootloader is not to be deployed on the rootfs, but to be built next to it. So it is more sensible to put the Makefile for a new/proprietary bootloader in $(BR2_EXTERNAL)/boot.
For $(BR2_EXTERNAL)/toolchain, a user may want to use a proprietary toolchain that is not available as a tarball and thus not installable via the traditional means.
Best regards,
ELB
PATCH v2 1/1 Fix selection of bootloaders from $(BR2_EXTERNAL)
Eric, Thomas, All,
On 2014-10-07 23:29 +0200, Eric Le Bihan spake thusly:
Quoted 8 lines · Thomas Petazzoni
Quoted 7 lines
Dear Eric Le Bihan,
Quoted 4 lines · Eric Le Bihan
If a package is based on "generic-package", pkg-generic.mk will compute the name of the
Kconfigvariable to use for checking if this package has been selected by the user.
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Unfortunately, this mechanism does not take into account the case where a bootloader is declared in a $(BR2_EXTERNAL)/boot directory.
So, even if the bootloader has been selected, it will not be added to $(TARGETS) and will not be built.
This patch fixes this issue, as well as handle toolchains.
[--SNIP--]
Quoted 8 lines
Quoted 7 lines
Well, this makes the assumption that $(BR2_EXTERNAL) bootloaders should be in boot/ and $(BR2_EXTERNAL) toolchain stuff should be in toolchain/.
In practice, the boot/ and toolchain/ organization in the main Buildroot does not necessarily need to be reflected in $(BR2_EXTERNAL):
you can have a bootloader in $(BR2_EXTERNAL)/package/foobar/, just name its optionBR2_PACKAGE_FOOBARand notBR2_TARGET_FOOBAR.
Quoted 8 lines
On the contrary, I find it confusing *not* to reflect the main Buildroot organization in $(BR2_EXTERNAL).
To me, the $(BR2_EXTERNAL)/package directory should contain Makefiles for programs to be deployed in the rootfs of the target or host tools to build them. But a bootloader is not to be deployed on the rootfs, but to be built next to it. So it is more sensible to put the
Makefilefor a new/proprietary bootloader in $(BR2_EXTERNAL)/boot.
I have to agree with Eric here: I think allowing (not enforcing) the same layout in br2-external as in Buildroot is a good thing.
Quoted 3 lines
For $(BR2_EXTERNAL)/toolchain, a user may want to use a proprietary toolchain that is not available as a tarball and thus not installable via the traditional means.
But does that even work at all?
Toolchains are not packages; br2-external was not designed to get new toolchain definitions. That it works, if it does at all, is just merely happenstance.
I wonder if/how we should/could get this to work.
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH v2 1/1 Fix selection of bootloaders from $(BR2_EXTERNAL)
Yann, Eric,
Quoted 8 lines · Yann E. MORIN
Quoted 5 lines
To me, the $(BR2_EXTERNAL)/package directory should contain Makefiles for programs to be deployed in the rootfs of the target or host tools to build them. But a bootloader is not to be deployed on the rootfs, but to be built next to it. So it is more sensible to put the
Makefilefor a new/proprietary bootloader in $(BR2_EXTERNAL)/boot.I have to agree with Eric here: I think allowing (not enforcing) the same layout in br2-external as in Buildroot is a good thing.
Well, ok. So let's go with the patch, but maybe with an update to the manual?
Quoted 11 lines
Quoted 3 lines
For $(BR2_EXTERNAL)/toolchain, a user may want to use a proprietary toolchain that is not available as a tarball and thus not installable via the traditional means.
But does that even work at all?
Toolchains are not packages; br2-external was not designed to get new toolchain definitions. That it works, if it does at all, is just merely happenstance.
I wonder if/how we should/could get this to work.
Clearly, that cannot work: how would one re-use the external toolchain logic to copy the sysroot, the target libraries and so on. Plus, the existing external toolchain mechanism already allows to use the tarball of a toolchain.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH v2 1/1 Fix selection of bootloaders from $(BR2_EXTERNAL)
Quoted 26 lines · Thomas Petazzoni
Yann, Eric,
Quoted 8 lines · Yann E. MORIN
Quoted 5 lines
To me, the $(BR2_EXTERNAL)/package directory should contain Makefiles for programs to be deployed in the rootfs of the target or host tools to build them. But a bootloader is not to be deployed on the rootfs, but to be built next to it. So it is more sensible to put the
Makefilefor a new/proprietary bootloader in $(BR2_EXTERNAL)/boot.I have to agree with Eric here: I think allowing (not enforcing) the same layout in br2-external as in Buildroot is a good thing.
Well, ok. So let's go with the patch, but maybe with an update to the manual?
Quoted 10 lines
Quoted 3 lines
For $(BR2_EXTERNAL)/toolchain, a user may want to use a proprietary toolchain that is not available as a tarball and thus not installable via the traditional means.
But does that even work at all?
Toolchains are not packages; br2-external was not designed to get new toolchain definitions. That it works, if it does at all, is just merely happenstance.
Quoted 6 lines
Quoted 1 line
I wonder if/how we should/could get this to work.
Clearly, that cannot work: how would one re-use the external toolchain logic to copy the sysroot, the target libraries and so on. Plus, the existing external toolchain mechanism already allows to use the tarball of a toolchain.
So, it would be best to remove the toolchain part of the patch, keeping only the bootloader one. I'll add a comment about it in docs/manual/customize-outside-br.txt and send a new version of the patch.
Best regards,
ELB