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

[Arnout Vandecappelle <arnout@mind.be>]

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