* [Buildroot] [git commit] fs: add rootfs dependencies to PACKAGES @ 2015-04-14 8:17 Thomas Petazzoni 2015-04-14 10:50 ` Arnout Vandecappelle 0 siblings, 1 reply; 11+ messages in thread From: Thomas Petazzoni @ 2015-04-14 8:17 UTC (permalink / raw) To: buildroot commit: http://git.buildroot.net/buildroot/commit/?id=4570dbcb14b394d8f3c97baf4c9e5f4f225d1d37 branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master The logic for creating most of the filesystem images requires a certain number of host packages to be built. However, those packages are not currently listed in the global PACKAGES variables, and they are not dependencies of any other package listed in the PACKAGES variable. While it does not have any practical implications, it makes sense to have those packages listed in the global PACKAGES variable, which this commit implements. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> --- fs/common.mk | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/fs/common.mk b/fs/common.mk index cac127f..41ee86d 100644 --- a/fs/common.mk +++ b/fs/common.mk @@ -106,6 +106,7 @@ rootfs-$(1): $$(BINARIES_DIR)/rootfs.$(1) $$(ROOTFS_$(2)_POST_TARGETS) ifeq ($$(BR2_TARGET_ROOTFS_$(2)),y) TARGETS_ROOTFS += rootfs-$(1) +PACKAGES += $$(ROOTFS_$(2)_DEPENDENCIES) endif endef ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [Buildroot] [git commit] fs: add rootfs dependencies to PACKAGES 2015-04-14 8:17 [Buildroot] [git commit] fs: add rootfs dependencies to PACKAGES Thomas Petazzoni @ 2015-04-14 10:50 ` Arnout Vandecappelle 2015-04-14 11:54 ` Thomas Petazzoni 0 siblings, 1 reply; 11+ messages in thread From: Arnout Vandecappelle @ 2015-04-14 10:50 UTC (permalink / raw) To: buildroot On 14/04/15 10:17, Thomas Petazzoni wrote: > commit: http://git.buildroot.net/buildroot/commit/?id=4570dbcb14b394d8f3c97baf4c9e5f4f225d1d37 > branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master > > The logic for creating most of the filesystem images requires a > certain number of host packages to be built. However, those packages > are not currently listed in the global PACKAGES variables, and they > are not dependencies of any other package listed in the PACKAGES > variable. > > While it does not have any practical implications, it makes sense to > have those packages listed in the global PACKAGES variable, which this > commit implements. > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> > --- > fs/common.mk | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/fs/common.mk b/fs/common.mk > index cac127f..41ee86d 100644 > --- a/fs/common.mk > +++ b/fs/common.mk > @@ -106,6 +106,7 @@ rootfs-$(1): $$(BINARIES_DIR)/rootfs.$(1) $$(ROOTFS_$(2)_POST_TARGETS) > > ifeq ($$(BR2_TARGET_ROOTFS_$(2)),y) > TARGETS_ROOTFS += rootfs-$(1) > +PACKAGES += $$(ROOTFS_$(2)_DEPENDENCIES) This will break the rest of your series for filesystems like ubi and initramfs that depend on another filesystem, because filesystems are not really packages so they shouldn't be in PACKAGES. Regards, Arnout > endif > endef > > _______________________________________________ > buildroot mailing list > buildroot at busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot > -- 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: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] [git commit] fs: add rootfs dependencies to PACKAGES 2015-04-14 10:50 ` Arnout Vandecappelle @ 2015-04-14 11:54 ` Thomas Petazzoni 2015-04-14 19:08 ` Arnout Vandecappelle 0 siblings, 1 reply; 11+ messages in thread From: Thomas Petazzoni @ 2015-04-14 11:54 UTC (permalink / raw) To: buildroot Dear Arnout Vandecappelle, On Tue, 14 Apr 2015 12:50:09 +0200, Arnout Vandecappelle wrote: > > diff --git a/fs/common.mk b/fs/common.mk > > index cac127f..41ee86d 100644 > > --- a/fs/common.mk > > +++ b/fs/common.mk > > @@ -106,6 +106,7 @@ rootfs-$(1): $$(BINARIES_DIR)/rootfs.$(1) $$(ROOTFS_$(2)_POST_TARGETS) > > > > ifeq ($$(BR2_TARGET_ROOTFS_$(2)),y) > > TARGETS_ROOTFS += rootfs-$(1) > > +PACKAGES += $$(ROOTFS_$(2)_DEPENDENCIES) > > This will break the rest of your series for filesystems like ubi and initramfs > that depend on another filesystem, because filesystems are not really packages > so they shouldn't be in PACKAGES. Aaah, indeed. Thanks a lot for catching this! But I believe the package dependencies should be in PACKAGES, so that "make external-deps", "make legal-info", "make source" and so on properly take into account the packages needed as a dependency of building a rootfs image. I can see several solutions here: 1) In the fs infrastructure, separate package dependencies from filesystem dependencies, like ROOTFS_UBI_FS_DEPENDENCIES = rootfs-ubifs, and ROOTFS_UBIFS_PACKAGE_DEPENDENCIES = host-mtd. This is probably the easiest solution, maybe not the prettiest one. 2) Simply filter out from $$(ROOTFS_$(2)_DEPENDENCIES) the targets that start with 'rootfs-' when adding them to the PACKAGES variable. Maybe not that pretty either, but very simple to do. 3) Adjust the fs infrastructure so that the rootfs-<foo> targets will also have rootfs-<foo>-legal-info, rootfs-<foo>-source, rootfs-<foo>-source-check and so on, a bit like we already implement rootfs-<foo>-show-depends. 4) Make the filesystem image stuff real packages. After all, they install something to $(BINARIES_DIR) and some other packages do it. Of course, the big difference is that they should have a special type so that they get built only after all other packages have been built/installed, the post-build scripts, overlay and so on have been handled. (1), (2) and (3) are pretty easy, (4) is a lot more work, and I don't know if the result will be very useful, but I don't know. Thoughts? Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] [git commit] fs: add rootfs dependencies to PACKAGES 2015-04-14 11:54 ` Thomas Petazzoni @ 2015-04-14 19:08 ` Arnout Vandecappelle 2015-04-14 21:46 ` Yann E. MORIN 2015-04-17 15:36 ` Thomas Petazzoni 0 siblings, 2 replies; 11+ messages in thread From: Arnout Vandecappelle @ 2015-04-14 19:08 UTC (permalink / raw) To: buildroot On 14/04/15 13:54, Thomas Petazzoni wrote: > Dear Arnout Vandecappelle, > > On Tue, 14 Apr 2015 12:50:09 +0200, Arnout Vandecappelle wrote: > >>> diff --git a/fs/common.mk b/fs/common.mk >>> index cac127f..41ee86d 100644 >>> --- a/fs/common.mk >>> +++ b/fs/common.mk >>> @@ -106,6 +106,7 @@ rootfs-$(1): $$(BINARIES_DIR)/rootfs.$(1) $$(ROOTFS_$(2)_POST_TARGETS) >>> >>> ifeq ($$(BR2_TARGET_ROOTFS_$(2)),y) >>> TARGETS_ROOTFS += rootfs-$(1) >>> +PACKAGES += $$(ROOTFS_$(2)_DEPENDENCIES) >> >> This will break the rest of your series for filesystems like ubi and initramfs >> that depend on another filesystem, because filesystems are not really packages >> so they shouldn't be in PACKAGES. > > Aaah, indeed. Thanks a lot for catching this! > > But I believe the package dependencies should be in PACKAGES, so that > "make external-deps", "make legal-info", "make source" and so on > properly take into account the packages needed as a dependency of > building a rootfs image. Yes of course. > > I can see several solutions here: > > 1) In the fs infrastructure, separate package dependencies from > filesystem dependencies, like ROOTFS_UBI_FS_DEPENDENCIES = > rootfs-ubifs, and ROOTFS_UBIFS_PACKAGE_DEPENDENCIES = host-mtd. > This is probably the easiest solution, maybe not the prettiest one. I'm not fond of this since it looks pretty complicated. > > 2) Simply filter out from $$(ROOTFS_$(2)_DEPENDENCIES) the targets > that start with 'rootfs-' when adding them to the PACKAGES variable. > Maybe not that pretty either, but very simple to do. Sounds acceptable, though not ideal. > > 3) Adjust the fs infrastructure so that the rootfs-<foo> targets will > also have rootfs-<foo>-legal-info, rootfs-<foo>-source, > rootfs-<foo>-source-check and so on, a bit like we already > implement rootfs-<foo>-show-depends. Then you can just as well go for 4). And anyway that's not enough because I think you have a circular dependency due to target-finalize. > > 4) Make the filesystem image stuff real packages. After all, they > install something to $(BINARIES_DIR) and some other packages do it. > Of course, the big difference is that they should have a special > type so that they get built only after all other packages have been > built/installed, the post-build scripts, overlay and so on have > been handled. This sounds more attractive to me, but as you say it's a lot of work. I think to make this possible we first have to converge to the solution where every package has a selected kconfig symbol, so PACKAGES can just be the list of selected target packages instead of relying on the contents of _DEPENDENCIES. So for now, I'd go for option 2. I've checked and it looks like rootfs-* are the only non-package dependencies that appear anywhere (I can't be 100% sure though). Regards, Arnout > (1), (2) and (3) are pretty easy, (4) is a lot more work, and I don't > know if the result will be very useful, but I don't know. > > Thoughts? > > Thomas > -- 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: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] [git commit] fs: add rootfs dependencies to PACKAGES 2015-04-14 19:08 ` Arnout Vandecappelle @ 2015-04-14 21:46 ` Yann E. MORIN 2015-04-17 15:36 ` Thomas Petazzoni 1 sibling, 0 replies; 11+ messages in thread From: Yann E. MORIN @ 2015-04-14 21:46 UTC (permalink / raw) To: buildroot Arnout, Thomas, All, On 2015-04-14 21:08 +0200, Arnout Vandecappelle spake thusly: > On 14/04/15 13:54, Thomas Petazzoni wrote: > > On Tue, 14 Apr 2015 12:50:09 +0200, Arnout Vandecappelle wrote: > >>> diff --git a/fs/common.mk b/fs/common.mk > >>> index cac127f..41ee86d 100644 > >>> --- a/fs/common.mk > >>> +++ b/fs/common.mk > >>> @@ -106,6 +106,7 @@ rootfs-$(1): $$(BINARIES_DIR)/rootfs.$(1) $$(ROOTFS_$(2)_POST_TARGETS) > >>> > >>> ifeq ($$(BR2_TARGET_ROOTFS_$(2)),y) > >>> TARGETS_ROOTFS += rootfs-$(1) > >>> +PACKAGES += $$(ROOTFS_$(2)_DEPENDENCIES) > >> This will break the rest of your series for filesystems like ubi and initramfs > >> that depend on another filesystem, because filesystems are not really packages > >> so they shouldn't be in PACKAGES. Damn, I tried a few FS, but not those taht depend on another one... > > I can see several solutions here: > > > > 1) In the fs infrastructure, separate package dependencies from > > filesystem dependencies, like ROOTFS_UBI_FS_DEPENDENCIES = > > rootfs-ubifs, and ROOTFS_UBIFS_PACKAGE_DEPENDENCIES = host-mtd. > > This is probably the easiest solution, maybe not the prettiest one. > I'm not fond of this since it looks pretty complicated. Agreed. > > 2) Simply filter out from $$(ROOTFS_$(2)_DEPENDENCIES) the targets > > that start with 'rootfs-' when adding them to the PACKAGES variable. > > Maybe not that pretty either, but very simple to do. > Sounds acceptable, though not ideal. This has the merit of being very simple and easy to do, so I'm OK with that, too. > > 3) Adjust the fs infrastructure so that the rootfs-<foo> targets will > > also have rootfs-<foo>-legal-info, rootfs-<foo>-source, > > rootfs-<foo>-source-check and so on, a bit like we already > > implement rootfs-<foo>-show-depends. > > Then you can just as well go for 4). And anyway that's not enough because I > think you have a circular dependency due to target-finalize. Like Arnout, I don't think there's much point in duplicating the pkg-infra. It might sound liek a good idea to implement those rules, but then it would make even more sense to go for 4. > > 4) Make the filesystem image stuff real packages. After all, they > > install something to $(BINARIES_DIR) and some other packages do it. > > Of course, the big difference is that they should have a special > > type so that they get built only after all other packages have been > > built/installed, the post-build scripts, overlay and so on have > > been handled. > > This sounds more attractive to me, but as you say it's a lot of work. > > I think to make this possible we first have to converge to the solution where > every package has a selected kconfig symbol, so PACKAGES can just be the list of > selected target packages instead of relying on the contents of _DEPENDENCIES. > > So for now, I'd go for option 2. I've checked and it looks like rootfs-* are > the only non-package dependencies that appear anywhere (I can't be 100% sure > though). Yeah, solution 2 is the best stop-gap measure for now. When things have calmed and dust has settled down a little, we can revisit this and go for 4. Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] [git commit] fs: add rootfs dependencies to PACKAGES 2015-04-14 19:08 ` Arnout Vandecappelle 2015-04-14 21:46 ` Yann E. MORIN @ 2015-04-17 15:36 ` Thomas Petazzoni 2015-04-17 16:09 ` Arnout Vandecappelle 2015-04-20 20:10 ` Peter Korsgaard 1 sibling, 2 replies; 11+ messages in thread From: Thomas Petazzoni @ 2015-04-17 15:36 UTC (permalink / raw) To: buildroot Dear Arnout Vandecappelle, On Tue, 14 Apr 2015 21:08:51 +0200, Arnout Vandecappelle wrote: > > 1) In the fs infrastructure, separate package dependencies from > > filesystem dependencies, like ROOTFS_UBI_FS_DEPENDENCIES = > > rootfs-ubifs, and ROOTFS_UBIFS_PACKAGE_DEPENDENCIES = host-mtd. > > This is probably the easiest solution, maybe not the prettiest one. > > I'm not fond of this since it looks pretty complicated. Complicated is maybe a bit too strong for just splitting things in two variables. But yes, it's yet another new variable with a very subtle associated use case. > > 2) Simply filter out from $$(ROOTFS_$(2)_DEPENDENCIES) the targets > > that start with 'rootfs-' when adding them to the PACKAGES variable. > > Maybe not that pretty either, but very simple to do. > > Sounds acceptable, though not ideal. Not ideal, but very minimal in its impact. > > 3) Adjust the fs infrastructure so that the rootfs-<foo> targets will > > also have rootfs-<foo>-legal-info, rootfs-<foo>-source, > > rootfs-<foo>-source-check and so on, a bit like we already > > implement rootfs-<foo>-show-depends. > > Then you can just as well go for 4). And anyway that's not enough because I > think you have a circular dependency due to target-finalize. I'm not sure to get your point here. Indeed (3) is just a way of avoiding all the work to do (4). I'm however, not sure to understand the circular dependency issue you're talking about. > > 4) Make the filesystem image stuff real packages. After all, they > > install something to $(BINARIES_DIR) and some other packages do it. > > Of course, the big difference is that they should have a special > > type so that they get built only after all other packages have been > > built/installed, the post-build scripts, overlay and so on have > > been handled. > > This sounds more attractive to me, but as you say it's a lot of work. Yes, it is. > I think to make this possible we first have to converge to the solution where > every package has a selected kconfig symbol, so PACKAGES can just be the list of > selected target packages instead of relying on the contents of _DEPENDENCIES. Is this something we want to get to? In practice, I believe most if not all of the target packages have a selected kconfig symbol. So the biggest change needed to get to this point would be the need to have selected kconfig symbols for all the host packages. Do we want to do that? I remember I did a proposal with this a long time ago, which allowed to only include the package .mk files that were actually needed in the build and therefore reducing the parsing time. However, the general feedback at the time was that the parsing time is not significant enough today to justify such a heavy modification. > So for now, I'd go for option 2. I've checked and it looks like rootfs-* are > the only non-package dependencies that appear anywhere (I can't be 100% sure > though). Ok, I'll go ahead and implement this. Thanks again for all the in-depth review, testing, and useful feedback! Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] [git commit] fs: add rootfs dependencies to PACKAGES 2015-04-17 15:36 ` Thomas Petazzoni @ 2015-04-17 16:09 ` Arnout Vandecappelle 2015-04-17 16:46 ` Thomas Petazzoni 2015-04-20 20:10 ` Peter Korsgaard 1 sibling, 1 reply; 11+ messages in thread From: Arnout Vandecappelle @ 2015-04-17 16:09 UTC (permalink / raw) To: buildroot On 17/04/15 17:36, Thomas Petazzoni wrote: > Dear Arnout Vandecappelle, > > On Tue, 14 Apr 2015 21:08:51 +0200, Arnout Vandecappelle wrote: [snip] >>> 3) Adjust the fs infrastructure so that the rootfs-<foo> targets will >>> also have rootfs-<foo>-legal-info, rootfs-<foo>-source, >>> rootfs-<foo>-source-check and so on, a bit like we already >>> implement rootfs-<foo>-show-depends. >> >> Then you can just as well go for 4). And anyway that's not enough because I >> think you have a circular dependency due to target-finalize. > > I'm not sure to get your point here. Indeed (3) is just a way of > avoiding all the work to do (4). I'm however, not sure to understand > the circular dependency issue you're talking about. The original piece of patch was snipped away: PACKAGES += $$(ROOTFS_$(2)_DEPENDENCIES) to which I replied that this is a problem for e.g. rootfs-ubifs in ROOTFS_UBI_DEPENDENCIES, because rootfs-ubifs is not a package and doesn't have all the package targets. So solution 3 that you propose is to add all the special targets to rootfs-*, so the rootfs'es actually do look like a package. Then we can safely do PACKAGES += $$(ROOTFS_$(2)_DEPENDENCIES) except for the following circular dependency: ROOTFS_UBI_DEPENDENCIES = rootfs-ubifs PACKAGES += $(ROOTFS_UBI_DEPENDENCIES) rootfs-ubi: $(ROOTFS_UBI_DEPENDENCIES) rootfs-ubifs: target-finalize target-finalize: $(PACKAGES) so rootfs-ubi -> rootfs-ubifs -> target-finalize -> rootfs-ubifs -> ... Regards, Arnout > >>> 4) Make the filesystem image stuff real packages. After all, they >>> install something to $(BINARIES_DIR) and some other packages do it. >>> Of course, the big difference is that they should have a special >>> type so that they get built only after all other packages have been >>> built/installed, the post-build scripts, overlay and so on have >>> been handled. >> >> This sounds more attractive to me, but as you say it's a lot of work. > > Yes, it is. > >> I think to make this possible we first have to converge to the solution where >> every package has a selected kconfig symbol, so PACKAGES can just be the list of >> selected target packages instead of relying on the contents of _DEPENDENCIES. > > Is this something we want to get to? In practice, I believe most if not > all of the target packages have a selected kconfig symbol. So the > biggest change needed to get to this point would be the need to have > selected kconfig symbols for all the host packages. Do we want to do > that? Yes I do. Not just for the thing below, but also because it makes infrastructure like legal-info and external-deps easier to understand if you don't have to mess with the dependencies but can just rely on a list of packages. > I remember I did a proposal with this a long time ago, which allowed to > only include the package .mk files that were actually needed in the > build and therefore reducing the parsing time. However, the general > feedback at the time was that the parsing time is not significant > enough today to justify such a heavy modification. As I remember it, the general feedback (at least my feedback) was that the fact that it makes tab-completion usable is a huge gain so certainly worth it, but that it was not actually working because of the missing host Kconfig symbols. Regards, Arnout >> So for now, I'd go for option 2. I've checked and it looks like rootfs-* are >> the only non-package dependencies that appear anywhere (I can't be 100% sure >> though). > > Ok, I'll go ahead and implement this. Thanks again for all the in-depth > review, testing, and useful feedback! > > Thomas > -- 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: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] [git commit] fs: add rootfs dependencies to PACKAGES 2015-04-17 16:09 ` Arnout Vandecappelle @ 2015-04-17 16:46 ` Thomas Petazzoni 2015-04-17 16:58 ` Arnout Vandecappelle 0 siblings, 1 reply; 11+ messages in thread From: Thomas Petazzoni @ 2015-04-17 16:46 UTC (permalink / raw) To: buildroot Dear Arnout Vandecappelle, On Fri, 17 Apr 2015 18:09:04 +0200, Arnout Vandecappelle wrote: > The original piece of patch was snipped away: > > PACKAGES += $$(ROOTFS_$(2)_DEPENDENCIES) > > to which I replied that this is a problem for e.g. rootfs-ubifs in > ROOTFS_UBI_DEPENDENCIES, because rootfs-ubifs is not a package and doesn't have > all the package targets. So solution 3 that you propose is to add all the > special targets to rootfs-*, so the rootfs'es actually do look like a package. > Then we can safely do > > PACKAGES += $$(ROOTFS_$(2)_DEPENDENCIES) > > except for the following circular dependency: > > ROOTFS_UBI_DEPENDENCIES = rootfs-ubifs > PACKAGES += $(ROOTFS_UBI_DEPENDENCIES) > rootfs-ubi: $(ROOTFS_UBI_DEPENDENCIES) > rootfs-ubifs: target-finalize > target-finalize: $(PACKAGES) > > so > > rootfs-ubi -> rootfs-ubifs -> target-finalize -> rootfs-ubifs -> ... Ah, right. We would then also have to do something like (2), i.e filtering rootfs-* targets as being special. > > Is this something we want to get to? In practice, I believe most if not > > all of the target packages have a selected kconfig symbol. So the > > biggest change needed to get to this point would be the need to have > > selected kconfig symbols for all the host packages. Do we want to do > > that? > > Yes I do. Not just for the thing below, but also because it makes > infrastructure like legal-info and external-deps easier to understand if you > don't have to mess with the dependencies but can just rely on a list of packages. I don't quite agree here. To me, traveling recursively through the dependencies is just the normal, 'make' way of doing things. It's not complicated, it's really natural. But maybe it's just a matter of perspective. > > I remember I did a proposal with this a long time ago, which allowed to > > only include the package .mk files that were actually needed in the > > build and therefore reducing the parsing time. However, the general > > feedback at the time was that the parsing time is not significant > > enough today to justify such a heavy modification. > > As I remember it, the general feedback (at least my feedback) was that the fact > that it makes tab-completion usable is a huge gain so certainly worth it, but > that it was not actually working because of the missing host Kconfig symbols. I'm not entirely sure to understand what sort of tab completion now works? Doing make fo<tab> becoming usable because the overall parsing time is more reasonable? However, one down side of not including all .mk files is that you will no longer be able to do 'make <pkg>-<something>' for a package that isn't enabled. And it is something I do everyday when doing BR development, especially 'make <pkg>-extract' and 'make <pkg>-patch', because that the easiest way to quickly get the source code of a given package extracted somewhere. And I can do this without having to go in menuconfig enable the package. Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] [git commit] fs: add rootfs dependencies to PACKAGES 2015-04-17 16:46 ` Thomas Petazzoni @ 2015-04-17 16:58 ` Arnout Vandecappelle 2015-04-18 12:35 ` Thomas Petazzoni 0 siblings, 1 reply; 11+ messages in thread From: Arnout Vandecappelle @ 2015-04-17 16:58 UTC (permalink / raw) To: buildroot On 17/04/15 18:46, Thomas Petazzoni wrote: > Dear Arnout Vandecappelle, > > On Fri, 17 Apr 2015 18:09:04 +0200, Arnout Vandecappelle wrote: [snip] >>> Is this something we want to get to? In practice, I believe most if not >>> all of the target packages have a selected kconfig symbol. So the >>> biggest change needed to get to this point would be the need to have >>> selected kconfig symbols for all the host packages. Do we want to do >>> that? >> >> Yes I do. Not just for the thing below, but also because it makes >> infrastructure like legal-info and external-deps easier to understand if you >> don't have to mess with the dependencies but can just rely on a list of packages. > > I don't quite agree here. To me, traveling recursively through the > dependencies is just the normal, 'make' way of doing things. It's not > complicated, it's really natural. For dependencies, yes. But the legal-info of package foo really has nothing to do with the legal-info of host package bar even if foo depends on bar. IMHO of course. But what I really mean is that something like this for external-deps would be quite simpler: external-deps: echo $(foreach pkg,$(PACKAGES),$($(pkg)_ALL_DOWNLOADS))) > > But maybe it's just a matter of perspective. > >>> I remember I did a proposal with this a long time ago, which allowed to >>> only include the package .mk files that were actually needed in the >>> build and therefore reducing the parsing time. However, the general >>> feedback at the time was that the parsing time is not significant >>> enough today to justify such a heavy modification. >> >> As I remember it, the general feedback (at least my feedback) was that the fact >> that it makes tab-completion usable is a huge gain so certainly worth it, but >> that it was not actually working because of the missing host Kconfig symbols. > > I'm not entirely sure to understand what sort of tab completion now > works? Doing make fo<tab> becoming usable because the overall parsing > time is more reasonable? Indeed. 'make -qnp' takes 3.5s on my laptop with a hot cache, full completion about 5 seconds. With a cold cache it's over 20 seconds. But I guess I should get an SSD. > However, one down side of not including all .mk files is that you will > no longer be able to do 'make <pkg>-<something>' for a package that > isn't enabled. And it is something I do everyday when doing BR > development, especially 'make <pkg>-extract' and 'make <pkg>-patch', > because that the easiest way to quickly get the source code of a given > package extracted somewhere. And I can do this without having to go in > menuconfig enable the package. I do that as well, but we could add a make variable to read all .mk files. Which was also one of the feedbacks on your patch series IIRC. Regards, Arnout -- 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: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] [git commit] fs: add rootfs dependencies to PACKAGES 2015-04-17 16:58 ` Arnout Vandecappelle @ 2015-04-18 12:35 ` Thomas Petazzoni 0 siblings, 0 replies; 11+ messages in thread From: Thomas Petazzoni @ 2015-04-18 12:35 UTC (permalink / raw) To: buildroot Arnout, On Fri, 17 Apr 2015 18:58:04 +0200, Arnout Vandecappelle wrote: > For dependencies, yes. But the legal-info of package foo really has nothing to > do with the legal-info of host package bar even if foo depends on bar. IMHO of > course. Well, it's very subjective :) > But what I really mean is that something like this for external-deps would be > quite simpler: > > external-deps: > echo $(foreach pkg,$(PACKAGES),$($(pkg)_ALL_DOWNLOADS))) Yes, it would indeed be shorter in code, and faster in execution. > > However, one down side of not including all .mk files is that you will > > no longer be able to do 'make <pkg>-<something>' for a package that > > isn't enabled. And it is something I do everyday when doing BR > > development, especially 'make <pkg>-extract' and 'make <pkg>-patch', > > because that the easiest way to quickly get the source code of a given > > package extracted somewhere. And I can do this without having to go in > > menuconfig enable the package. > > I do that as well, but we could add a make variable to read all .mk files. > Which was also one of the feedbacks on your patch series IIRC. That's indeed a possibility. Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] [git commit] fs: add rootfs dependencies to PACKAGES 2015-04-17 15:36 ` Thomas Petazzoni 2015-04-17 16:09 ` Arnout Vandecappelle @ 2015-04-20 20:10 ` Peter Korsgaard 1 sibling, 0 replies; 11+ messages in thread From: Peter Korsgaard @ 2015-04-20 20:10 UTC (permalink / raw) To: buildroot >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: Hi, >> > 2) Simply filter out from $$(ROOTFS_$(2)_DEPENDENCIES) the targets >> > that start with 'rootfs-' when adding them to the PACKAGES variable. >> > Maybe not that pretty either, but very simple to do. >> >> Sounds acceptable, though not ideal. > Not ideal, but very minimal in its impact. Indeed. I also think this is the way to go right now. >> So for now, I'd go for option 2. I've checked and it looks like rootfs-* are >> the only non-package dependencies that appear anywhere (I can't be 100% sure >> though). > Ok, I'll go ahead and implement this. Thanks again for all the in-depth > review, testing, and useful feedback! Thanks! -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2015-04-20 20:10 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-04-14 8:17 [Buildroot] [git commit] fs: add rootfs dependencies to PACKAGES Thomas Petazzoni 2015-04-14 10:50 ` Arnout Vandecappelle 2015-04-14 11:54 ` Thomas Petazzoni 2015-04-14 19:08 ` Arnout Vandecappelle 2015-04-14 21:46 ` Yann E. MORIN 2015-04-17 15:36 ` Thomas Petazzoni 2015-04-17 16:09 ` Arnout Vandecappelle 2015-04-17 16:46 ` Thomas Petazzoni 2015-04-17 16:58 ` Arnout Vandecappelle 2015-04-18 12:35 ` Thomas Petazzoni 2015-04-20 20:10 ` Peter Korsgaard
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.