pkg-kconfig: .config target needs to take into account package dependencies
PATCH 1/1 pkg-kconfig: .config target needs to take into account package dependencies
It is possible that the package's kconfig system needs one of its dependencies to be built before. This is for example the case for the linux-backports project, which needs a reference to the linux kernel configuration.
Therefore, the dependencies of $$($(2)_TARGET_CONFIGURE) should be copied as $(2)_DIR/.config's dependencies. The dependency on _PATCH was already there (implicitly, through $$($(2)_KCONFIG_FILE)), only the dependency on $$($(2)_DEPENDENCIES) should be added.
--- package/pkg-kconfig.mk | 5 +++++ 1 file changed, 5 insertions(+)
package/pkg-kconfig.mk +5 -0
@@ -57,6 +57,11 @@ $$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES): | $(1)-patch fi; \ done +# Generating the .config file is part of the configure step of the package +# infrastructure, so it should be ordered like it. IOW, it should take over +# its dependencies. +$$($(2)_DIR)/.config: | $$($(2)_FINAL_DEPENDENCIES) + # The specified source configuration file and any additional configuration file # fragments are merged together to .config, after the package has been patched. # Since the file could be a defconfig file it needs to be expanded to a
Signature · 1 line
2.1.4
PATCH 1/1 pkg-kconfig: .config target needs to take into account package dependencies
Arnout, All,
On 2015-07-03 22:42 +0200, Arnout Vandecappelle (Essensium/Mind) spake thusly:
Quoted 21 lines
It is possible that the package's kconfig system needs one of its dependencies to be built before. This is for example the case for the linux-backports project, which needs a reference to the linux kernel configuration.
Therefore, the dependencies of $$($(2)_TARGET_CONFIGURE) should be copied as $(2)_DIR/.config's dependencies. The dependency on
_PATCHwas already there (implicitly, through $$($(2)_KCONFIG_FILE)), only the dependency on $$($(2)_DEPENDENCIES) should be added.Cc Petr Vorel <[email protected]>--- package/pkg-kconfig.mk | 5 +++++ 1 file changed, 5 insertions(+)package/pkg-kconfig.mk +0
-0
package/pkg-kconfig.mk $$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES): | $(1)-patch · line 63
Quoted 7 lines
package/pkg-kconfig.mk +4
-0@@ -57,6 +57,11 @@ $$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES): | $(1)-patch fi; \ done +# Generating the .config file is part of the configure step of the package +# infrastructure, so it should be ordered like it. IOW, it should take over +# its dependencies. +$$($(2)_DIR)/.config: | $$($(2)_FINAL_DEPENDENCIES)
OK, I see the point.
However, when Thomas DS. and I did the infra, we explicitly avoided this dependency, for a simple reason: we did not want to have to build the dependencies of a package just to 'menuconfig' it, like so:
make menuconfig <- enable kernel
make linux-menuconfig
Currently, all we need@that moment is that linux be downloaded, extracted and patched, then we can show the menuconfig.
With your proposed patch, it means all the Linux dependencies (host-kmod, lzop...) will have to be built before we can show the menuconfig. This was the situation we were in before we had the kconfig-package infra, and it is *very* frustrating... :-(
I would like to avoid this as much as possible. Although I understand the reason for linux-backports, can we find a better solution? I would even be OK with an ad-hoc solution just for linux-backports...
Regards,
Yann E. MORIN.
Quoted 10 lines
package/pkg-kconfig.mk +0
-0# The specified source configuration file and any additional configuration file # fragments are merged together to .config, after the package has been patched. # Since the file could be a defconfig file it needs to be expanded to aSignature · 6 lines
2.1.4 _______________________________________________ buildroot mailing list buildroot at busybox.net http://lists.busybox.net/mailman/listinfo/buildroot
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 pkg-kconfig: .config target needs to take into account package dependencies
Hello,
Quoted 14 lines · Yann E. MORIN
package/pkg-kconfig.mk $$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES): | $(1)-patch · line 63
Quoted 4 lines
package/pkg-kconfig.mk +4
-0+# Generating the .config file is part of the configure step of the package +# infrastructure, so it should be ordered like it. IOW, it should take over +# its dependencies. +$$($(2)_DIR)/.config: | $$($(2)_FINAL_DEPENDENCIES)OK, I see the point.
However, when Thomas DS. and I did the infra, we explicitly avoided this dependency, for a simple reason: we did not want to have to build the dependencies of a package just to 'menuconfig' it, like so:
make menuconfig <- enable kernel
make linux-menuconfig
Quoted 7 lines
Currently, all we need at that moment is that linux be downloaded, extracted and patched, then we can show the menuconfig.
With your proposed patch, it means all the Linux dependencies (host-kmod, lzop...) will have to be built before we can show the menuconfig. This was the situation we were in before we had the kconfig-package infra, and it is *very* frustrating... :-(
I agree that having to build all dependencies of linux just to run "make linux-menuconfig" is a bit annoying. So finding a solution to keep this behavior would be nice.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 pkg-kconfig: .config target needs to take into account package dependencies
Quoted 21 lines · Thomas Petazzoni
Hello,
Quoted 17 lines · Yann E. MORIN
package/pkg-kconfig.mk $$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES): | $(1)-patch · line 63
Quoted 4 lines
package/pkg-kconfig.mk +4
-0+# Generating the .config file is part of the configure step of the package +# infrastructure, so it should be ordered like it. IOW, it should take over +# its dependencies. +$$($(2)_DIR)/.config: | $$($(2)_FINAL_DEPENDENCIES)OK, I see the point.
However, when Thomas DS. and I did the infra, we explicitly avoided this dependency, for a simple reason: we did not want to have to build the dependencies of a package just to 'menuconfig' it, like so:
make menuconfig <- enable kernel
make linux-menuconfigCurrently, all we need at that moment is that linux be downloaded, extracted and patched, then we can show the menuconfig.
Quoted 8 lines
Quoted 4 lines
With your proposed patch, it means all the Linux dependencies (host-kmod, lzop...) will have to be built before we can show the menuconfig. This was the situation we were in before we had the kconfig-package infra, and it is *very* frustrating... :-(
I agree that having to build all dependencies of linux just to run "make linux-menuconfig" is a bit annoying. So finding a solution to keep this behavior would be nice.
OK, fair enough, marked as rejected.
This does warrant a comment in pkg-kconfig.mk to avoid rehashing this in the
future.
Regards,
Arnout
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