Hi Heinrich, On Sat, 19 Apr 2025 at 13:22, Heinrich Schuchardt <heinrich.schucha...@canonical.com> wrote: > > > > Simon Glass <s...@chromium.org> schrieb am Sa., 19. Apr. 2025, 16:14: >> >> Hi Heinrich, >> >> On Sat, 19 Apr 2025 at 04:20, Heinrich Schuchardt >> <heinrich.schucha...@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.sch...@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.
I'm happy to discuss the merits of both approaches, but remember, I am your mirror. So if you can be flexible, so can I. Maybe Tom might put up with having a file? We only need to list the combinations we want to test in CI. Regards, Simon > > Best regards > > Heinrich > >> >> Regards, >> Simon >> >> [1] >> https://patchwork.ozlabs.org/project/uboot/patch/20241108152350.3686274-9-...@chromium.org/ >> [2] https://lore.kernel.org/u-boot/20250329002537.GN93000@bill-the-cat/
