On Mon, Apr 21, 2025 at 09:31:19AM -0600, Simon Glass wrote: > 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.
I wish you paid more attention to the mailing lists sometimes Simon. What we have today for fragments is me having compromised 2 or 3 times already (and the problems they've caused weren't ones I would have predicted). But no, what you want is just wrong on so many levels. And frankly, I think Heinrich's approach shows the problem with using fragments in some cases. This should have been some defconfigs to start with. But I'm willing to compromise, again, and take adding some special build jobs to CI (which slows down the pipelines, as there's non-trivial constant time bring-up/tear down and we have a hard limit of 10 concurrent Azure jobs) and more arguments for buildman because maybe there's a use case for fragments as arguments I'm not seeing. -- Tom
signature.asc
Description: PGP signature
