Re: [PATCH 3/9] buildman: Support #include files in defconfigs

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 2731 bytes --]

On Fri, Nov 15, 2024 at 07:26:56AM -0700, Simon Glass wrote:

[snip]
> This patch fixes the 'buildman doesn't support handling #include files
> correctly yet' problem.

This is good, and what I wanted to see. And the final patch in this
series shows that we can indeed trim down many of the current #include
users to be fewer lines, and that things like:
$ cat configs/qemu_arm64_acpi_defconfig
#include <configs/qemu_arm64_defconfig>
#include <board/emulation/configs/acpi.config>

Now work with buildman, too.

> My other patch proposes a way to allow
> buildman to build things with fragments. I'm sure there are other
> options, but since buildman can potentially build all the boards in
> U-Boot, it needs some way to know whether to apply a fragment.

I keep going back to, why does it need this? If it's important enough
for CI, it's now a 2 line (or so) defconfig file. Done. No new code to
maintain. No new jobs to run. And _every_ config doesn't need to be done
in CI, either. We have things like
board/asus/transformer-t20/configs/tf101g.config which just change the
device tree to be used. And once that's upstream, there's no value in CI
building that (there's no value today in CI building that, we don't do
anything with device tree warnings, etc).

> For building a single board (e.g. with --board), buildman could
> perhaps allow fragments to be specified?

On the one hand, yes, it would let me think about changing how I do CI
on hardware to use buildman instead, but on the other hand I don't think
it would make anything easier, so I probably wouldn't.

> It seems you are asking people to create boards containing the
> required combinations?

Yes.

> I see with TI there are two possible fragments.

More than that, if you count cases like
configs/am62x_evm_a53_ethboot_defconfig and
configs/am68_sk_a72_defconfig where the latter is just changing device
tree BUT the desire is for end users to trivially and non-confusingly
know how to build the board, so "am68_sk_a72_defconfig" and not
"j721s2_evm_a72_defconfig am68_sk_a72.config".

> How do we keep those working in CI? If you are wanting people to
> create boards for each (which is fine by me), can we produce an error
> when a fragment is not used by any board?

Not all fragments must be in CI. Not all fragments are "obvious" either.
It's not always clear when a fragment is or is not valid with another
defconfig. Solving these kind of problems seems like it's a high effort
and low return on engineering time compared with "make a defconfig".
Especially now that we can lower the effort bar on making the defconfig
as one tested with "make" will now work with buildman too.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]