> Le 8 déc. 2023 à 16:39, Elliott Mitchell <ehem+open...@m5p.com> a écrit :
>
> On Fri, Dec 08, 2023 at 11:14:38AM +0100, Robert Marko wrote:
>> On Fri, 8 Dec 2023 at 11:13, Piotr Dymacz <pep...@gmail.com> wrote:
>>>
>>> On 8.12.2023 11:02, Robert Marko wrote:
>>>> On Fri, 8 Dec 2023 at 11:01, Piotr Dymacz <pep...@gmail.com> wrote:
>>>>>
>>>>> Would it make sense to rename qualcommax to qualcomm and make ipq95xx
>>>>> just another subtarget of it (I'm aware of A53 vs. A73)?
>>>>
>>>> That depends on how much is shared between the AX SoC-s and the BE
>>>> ones(IPQ95xx and IPQ53xx).
>>>
>>> I would say enough to keep them together.
>>>
>>>> But, I would prefer that or qualcommbe target where new BE SoC-s will
>>>> be subtargets.
>>>
>>> I'm personally more a fan of limiting number of top targets and deal
>>> with differences under subtargets.
>>
>> Same here, better than to add more targets especially since a lot is shared.
>
> This leads to needing more levels of organization. Instead of simply
> TARGET/SUBTARGET, you end up needing TARGET/SUBTARGET/SUBSUBTARGET. If
> this is going to be done, then the implementation should allow for an
> arbitrary number of levels.
>
> A makefile fragment I created for testing:
>
> foo := foo0
> SUBfoo := foo1
> SUBSUBfoo := foo2
>
> define recur
> $(info current is $(1), value is $($(1))))
> ignore := $(if $(filter $(flavor SUB$(1)),undefined),,$(call recur,SUB$(1)))
> endef
>
> ignore := $(call recur,foo)
>
> all: test.make
> @true
>
> So an arbitrary number of levels seems doable.
No.
> 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.
My 2c.
T.
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
