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.