adding new subtargets

[Thibaut]

[trimming CC-list and changing subject to match content]

> Le 8 déc. 2023 à 23:48, Elliott Mitchell <ehem+openwrt at m5p.com> a écrit :
> 
> On Fri, Dec 08, 2023 at 06:53:31PM +0100, Thibaut wrote:
>> 
>>> Le 8 déc. 2023 à 16:39, Elliott Mitchell <ehem+openwrt at m5p.com> a écrit :
>>> 
[…]
>>> Will mean rather
>>> substantial changes to the build system though.  I tend to favor this
>>> as the 2 level limitation is already placing restrictions on the scaling
>>> of the build count.
>> 
>> It appears most people do not understand that {sub}+targets use the exact same amount of build resources *each* as a whole target. There is no benefit, from the PoV of the (phase1) builders, to having more subtargets vs more targets: either way, growing either number indefinitely is simply not sustainable. Please don’t do that.
>> 
> 
> So, you would prefer to have all of a small cupcake, to a slice of a
> much larger cake?
> 
> You would prefer to be the big fish in the small pond to the small fish
> in the much larger lake?

?

> This is not an invalid choice, but usually projects prefer to grow than
> shrink.  Also, while having more levels should allow better organization
> and then more growth; making growth possible does not force growth to
> occur.

Famous last words.

I don’t think the project is in a situation to throw limitless resources at its build workload, but I’m happy to be proven wrong. Fact: unlimited/unabated growth in a finite environment seldom gives lasting results.

> What I've observed from rather a lot of wildly different builds in the
> past month differs.  Most of any OpenWRT build is unshared, but some
> portions are reused and substantially greater portions could be reused.

Provided that you can guarantee no bits leak across builds and 100% reproducibility, sure.

> Notably the compiler was reused.

Not on phase1. Toolchain is rebuilt for every (sub)target.
(I won’t discuss phase2 here which has its own problems, like rebuilding the entire repo for every package bump).

>   If steps were taken to allow reusing
> unpacked kernel source, the kernel would only need to be unpacked once
> (some of the patches I've sent aim in this direction).
> 
> One thing I've noticed is the single-thread portions are a *major*
> holdback at this point.  The single-thread unpacking of various tarballs
> completely overwhelmed the portions of builds which used multiple
> processors.
> 
> Right now my storage is sick and providing poor write performance (wow,
> that battery-backed cache was *impressive*!), yet all OpenWRT builds
> averaged less than a single processor in use.  That is rather concerning.

No need to be concerned, this does not occur on autobuilder hardware.

tl;dr: new (sub)targets each imply a complete « make world » cycle from a clean git checkout on phase1: it’s a substantial load, especially when only a handful of devices are concerned (hence for instance keeping qoriq source-only). Accommodating new devices should therefore leverage as much as possible *existing* (sub)targets (or consider staying source-only).

Alternatively, you’re welcome to rewrite the build system to make it more scalable.

T.