[PATCH v2 1/3] buildman: allow specifying configuration fragments

[Heinrich Schuchardt]

Simon Glass <sjg at chromium.org> schrieb am Sa., 19. Apr. 2025, 16:14:

> Hi Heinrich,
>
> On Sat, 19 Apr 2025 at 04:20, Heinrich Schuchardt
> <heinrich.schuchardt at canonical.com> wrote:
> >
> > On 4/18/25 13:39, Simon Glass wrote:
> > > Hi Quentin,
> > >
> > > On Fri, 18 Apr 2025 at 05:27, Quentin Schulz <quentin.schulz at cherry.de>
> wrote:
> > >>
> > >> Hi Heinrich,
> > >>
> > >> On 4/17/25 12:40 AM, Heinrich Schuchardt wrote:
> > >>> Currently we are no able to build with configuration fragments in
> our CI.
> > >>> With this patch buildman gets a new argument --fragments for passing
> a
> > >>> comma separated list of configuration fragments to add to the board
> > >>> defconfigs, e.g.
> > >>>
> > >>>       tools/buildman/buildman \
> > >>>       -o build \
> > >>>       -k qemu-riscv64_smode \
> > >>>       --fragments acpi.config
> > >>>
> > >>
> > >> What about using:
> > >>
> > >> --fragment acpi.config --fragment fragment2.config
> > >>
> > >> ?
> > >
> > > Yes that could be useful. It would also allow wildcards, although the
> > > code would need to drop the config/ directory prefix. Also, I see that
> > > -z is available so perhaps that could be a (bad) short option?
> >
> > Hello Simon,
> >
> > What do you mean by useful?
> >
> > --fragments a,b conveys the same information as --fragment a --fragment
> b.
> >
> > We are not passing any config/ directory with the fragment names.
> >
> > Using wildcards in does not depend on how fragment names are passed.
> >
> > As maintainer of buildman, please, clearly express how you want the
> > fragment names to be passed. "Could be useful" does not indicate any
> > decision but let's me hang in limbo.
>
> NAK
>
> We need a file which lists the valid boards for each config fragment.
> Buildman should parse that and it should be possible (with an argument
> like --build-all-fragments) to build all fragments for a board (or all
> boards), to make sure that things actually build. See [1]
>
> So until that is done I'm going to NAK the whole concept[2].
>

Building all possible permutations can easily result in excessive numbers
of CI builds.

We have been breaking ACPI builds multiple times and now you block testing.

I am not amused.

Best regards

Heinrich


> Regards,
> Simon
>
> [1]
> https://patchwork.ozlabs.org/project/uboot/patch/20241108152350.3686274-9-sjg@chromium.org/
> [2] https://lore.kernel.org/u-boot/20250329002537.GN93000@bill-the-cat/
>