[Buildroot] [git commit] fs: add rootfs dependencies to PACKAGES

[Buildroot] [git commit] fs: add rootfs dependencies to PACKAGES

[Thomas Petazzoni]

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
 

[Buildroot] [git commit] fs: add rootfs dependencies to PACKAGES

[Arnout Vandecappelle]

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

[Buildroot] [git commit] fs: add rootfs dependencies to PACKAGES

[Thomas Petazzoni]

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

[Buildroot] [git commit] fs: add rootfs dependencies to PACKAGES

[Arnout Vandecappelle]

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

[Buildroot] [git commit] fs: add rootfs dependencies to PACKAGES

[Yann E. MORIN]

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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [git commit] fs: add rootfs dependencies to PACKAGES

[Thomas Petazzoni]

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

[Buildroot] [git commit] fs: add rootfs dependencies to PACKAGES

[Arnout Vandecappelle]

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

[Buildroot] [git commit] fs: add rootfs dependencies to PACKAGES

[Thomas Petazzoni]

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

[Buildroot] [git commit] fs: add rootfs dependencies to PACKAGES

[Arnout Vandecappelle]

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

[Buildroot] [git commit] fs: add rootfs dependencies to PACKAGES

[Thomas Petazzoni]

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

[Buildroot] [git commit] fs: add rootfs dependencies to PACKAGES

[Peter Korsgaard]

>>>>> "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