linux: kconfig needs the toolchain
PATCH 1/1 linux: kconfig needs the toolchain
Starting with linux-4.18, the kconfig from the kernel can call to the compiler to test its capabilities; see:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/Kconfig.include
Like is done in the kconfig-package infra for the dependency on $(1)-patch, we use an order-only prerequisites on the toolchain, to guarantee the compiler is available before we can display the kconfig of the kernel.
--- linux/linux.mk | 7 +++++++ 1 file changed, 7 insertions(+)
linux/linux.mk +7 -0
@@ -510,6 +510,13 @@ endif # BR_BUILDING $(eval $(kconfig-package)) +# Starting with linux-4.18, the kconfig in the kernel calls +# the cross-compiler to check its capabilities. So we need +# the toolchain before we can call our configurators. +# Also, since we need LINUX_DIR, we must be after the call +# to kconfig-package, above. +$(LINUX_DIR)/.config: | toolchain + # Support for rebuilding the kernel after the cpio archive has # been generated. .PHONY: linux-rebuild-with-initramfs
Signature · 1 line
2.14.1
PATCH 1/1 linux: kconfig needs the toolchain
Quoted 9 lines · Yann E. MORIN
Starting with linux-4.18, the kconfig from the kernel can call to the compiler to test its capabilities; see:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/Kconfig.include
Like is done in the kconfig-package infra for the dependency on $(1)-patch, we use an order-only prerequisites on the toolchain, to guarantee the compiler is available before we can display the kconfig of the kernel.
You actually want to say here why an order-only dependency and not a normal
dependency: "Since 'toolchain' is a phony target and therefore always out of date, a normal dependency would cause the .config target to be rebuilt on each invocation of make."
Quoted 13 lines
Signed-off-by "Yann E. MORIN" <[email protected]>Cc Thomas Petazzoni <[email protected]>Cc Arnout Vandecappelle <[email protected]>--- linux/linux.mk | 7 +++++++ 1 file changed, 7 insertions(+)linux/linux.mk +0
-0
linux/linux.mk endif # BR_BUILDING · line 518
Quoted 9 lines
linux/linux.mk +6
-0@@ -510,6 +510,13 @@ endif # BR_BUILDING $(eval $(kconfig-package)) +# Starting with linux-4.18, the kconfig in the kernel calls +# the cross-compiler to check its capabilities. So we need +# the toolchain before we can call our configurators. +# Also, since we need LINUX_DIR, we must be after the call +# to kconfig-package, above. +$(LINUX_DIR)/.config: | toolchain
I think we want to avoid using LINUX_DIR, and instead use LINUX_SRCDIR orLINUX_BUILDDIR, no? For the eventual source/build directory split?
Regards,
Arnout
Quoted 5 lines
linux/linux.mk +1
-0+ # Support for rebuilding the kernel after the cpio archive has # been generated. .PHONY: linux-rebuild-with-initramfs
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 1/1 linux: kconfig needs the toolchain
Hello,
Quoted 8 lines · Arnout Vandecappelle
Quoted 4 lines
Like is done in the kconfig-package infra for the dependency on $(1)-patch, we use an order-only prerequisites on the toolchain, to guarantee the compiler is available before we can display the kconfig of the kernel.
You actually want to say here why an order-only dependency and not a normal
dependency: "Since 'toolchain' is a phony target and therefore always out of date, a normal dependency would cause the .config target to be rebuilt on each invocation of make."
When looking at the patch, my initial reaction was: why is the dependency on the .config file, rather than on the -menuconfig/-xconfig/-nconfig/... targets. Those are phony targets, so a normal dependency would work.
This could even be pushed one level up to the pkg-kconfig infrastructure, as we're pretty likely to see other packages go down this route in the future maybe ? Of course, it should be optional.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
PATCH 1/1 linux: kconfig needs the toolchain
Thomas, All,
On 2018-08-01 08:35 +0200, Thomas Petazzoni spake thusly:
Quoted 10 lines · Arnout Vandecappelle
Quoted 8 lines
Quoted 4 lines
Like is done in the kconfig-package infra for the dependency on $(1)-patch, we use an order-only prerequisites on the toolchain, to guarantee the compiler is available before we can display the kconfig of the kernel.
You actually want to say here why an order-only dependency and not a normal
dependency: "Since 'toolchain' is a phony target and therefore always out of date, a normal dependency would cause the .config target to be rebuilt on each invocation of make."
Quoted 4 lines
When looking at the patch, my initial reaction was: why is the dependency on the .config file, rather than on the -menuconfig/-xconfig/-nconfig/... targets. Those are phony targets, so a normal dependency would work.
We need the toolchain to generate the .config file, even in a nromal build, i.e. not just for the menuconfig et al.
I.e. running 'make clean; make' should also build the toolchain before the linux configuration, which is part of the kconfig infra.
Agreed that it would not happen in practice, but for theoretical correctness, it is also needed in this case.
Quoted 3 lines
This could even be pushed one level up to the pkg-kconfig infrastructure, as we're pretty likely to see other packages go down this route in the future maybe ? Of course, it should be optional.
Well, I also thought about that, but decided against, because we don't want to generalise a behaviour based on a single case.
As for the configurability, I would have gone with:
FOO_KCONFIG_NEEDS_CC = YES
because that is actually what it wants currently.
But in the future, it might also want to call 'dtc' to check whether it supports overlays, or call 'openssl' to check if a cypher is available. So we'd have to expand this to:
FOO_KCONFIG_DEPENDENCIES = toolchain host-dtc host-openssl
Or whatev'...
So I'd prefer waiting, and hard-coding that one peculiarity within the only user so far, the linux kernel.
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 1/1 linux: kconfig needs the toolchain
Thomas, Arnout, All,
On 2018-08-01 17:48 +0200, Yann E. MORIN spake thusly:
Quoted 6 lines
On 2018-08-01 08:35 +0200, Thomas Petazzoni spake thusly:
Quoted 5 lines · Arnout Vandecappelle
Quoted 4 lines
Quoted 4 lines
Like is done in the kconfig-package infra for the dependency on $(1)-patch, we use an order-only prerequisites on the toolchain, to guarantee the compiler is available before we can display the kconfig of the kernel.
[--SNIP--]
Quoted 6 lines
Quoted 3 lines
This could even be pushed one level up to the pkg-kconfig infrastructure, as we're pretty likely to see other packages go down this route in the future maybe ? Of course, it should be optional.
Well, I also thought about that, but decided against, because we don't want to generalise a behaviour based on a single case.
[--SNIP--]
Quoted 2 lines
So I'd prefer waiting, and hard-coding that one peculiarity within the only user so far, the linux kernel.
And now, I changed my mind, seeing that the curent state of oaffairs with host-flex and host-bison is already broken...
I'll post an updated series that implements this at the kconfig level soon-ish.
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 1/1 linux: kconfig needs the toolchain
In reply to Arnout VandecappelleArnout, All,
On 2018-08-01 00:21 +0200, Arnout Vandecappelle spake thusly:
Quoted 6 lines · Yann E. MORIN
Quoted 5 lines
Starting with linux-4.18, the kconfig from the kernel can call to the compiler to test its capabilities; see:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/Kconfig.include
Quoted 8 lines
Quoted 4 lines
Like is done in the kconfig-package infra for the dependency on $(1)-patch, we use an order-only prerequisites on the toolchain, to guarantee the compiler is available before we can display the kconfig of the kernel.
You actually want to say here why an order-only dependency and not a normal
dependency: "Since 'toolchain' is a phony target and therefore always out of date, a normal dependency would cause the .config target to be rebuilt on each invocation of make."
ACK
Quoted 15 lines
Quoted 15 lines
Signed-off-by "Yann E. MORIN" <[email protected]>Cc Thomas Petazzoni <[email protected]>Cc Arnout Vandecappelle <[email protected]>--- linux/linux.mk | 7 +++++++ 1 file changed, 7 insertions(+)linux/linux.mk +0
-0@@ -510,6 +510,13 @@ endif # BR_BUILDING $(eval $(kconfig-package))
Quoted 9 lines
linux/linux.mk endif # BR_BUILDING · line 518
Quoted 6 lines
linux/linux.mk +6
-0+# Starting with linux-4.18, the kconfig in the kernel calls +# the cross-compiler to check its capabilities. So we need +# the toolchain before we can call our configurators. +# Also, since we need LINUX_DIR, we must be after the call +# to kconfig-package, above. +$(LINUX_DIR)/.config: | toolchainI think we want to avoid using
LINUX_DIR, and instead useLINUX_SRCDIRorLINUX_BUILDDIR, no? For the eventual source/build directory split?
Well, LINUX_DIR is already used below, for the rules doing the rebuild with the initramfs.
And I don't want to mix-n-match the variables just yet...
But if the consensus from others point toward using LINUX_BUILDDIR, then I'll change.
Regards,
Yann E. MORIN.
Quoted 16 lines
Regards,
ArnoutQuoted 5 lines
linux/linux.mk +1
-0+ # Support for rebuilding the kernel after the cpio archive has # been generated. .PHONY: linux-rebuild-with-initramfsSignature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
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. | '------------------------------^-------^------------------^--------------------'