[PATCH v2] sandbox: Add a build without CMDLINE

[Simon Glass]

Hi Tom,

On Fri, 1 Nov 2024 at 17:26, Tom Rini <trini at konsulko.com> wrote:
>
> On Fri, Nov 01, 2024 at 04:38:26PM +0100, Simon Glass wrote:
> > Hi Tom,
> >
> > On Sun, 27 Oct 2024 at 15:56, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Sun, Oct 27, 2024 at 03:52:02PM +0100, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Sun, 27 Oct 2024 at 00:33, Tom Rini <trini at konsulko.com> wrote:
> > > > >
> > > > > On Sat, Oct 26, 2024 at 02:02:49PM +0200, Simon Glass wrote:
> > > > >
> > > > > > Something this breaks, so add a build to keep it working. Since sandbox
> > > > > > enables a lot of options, it is a good board to use. The new config is
> > > > > > created simply by copying the existing sandbox and turning off CMDLINE
> > > > > >
> > > > > > Once we have tests for non-CMDLINE operation, this can be adjusted to
> > > > > > run those tests.
> > > > > >
> > > > > > Create a new build which will be picked up by CI. Update the maintainer
> > > > > > entry as well.
> > > > > >
> > > > > > Signed-off-by: Simon Glass <sjg at chromium.org>
> > > > > > ---
> > > > > >
> > > > > > Changes in v2:
> > > > > > - Create a new build instead of messing with CI
> > > > > >
> > > > > >  MAINTAINERS                         |   1 +
> > > > > >  configs/sandbox_nocmdline_defconfig | 365 ++++++++++++++++++++++++++++
> > > > > >  2 files changed, 366 insertions(+)
> > > > > >  create mode 100644 configs/sandbox_nocmdline_defconfig
> > > > >
> > > > > Please use the #include mechanism instead of a full config that will
> > > > > also now have to be kept in sync.
> > > >
> > > > Hmmm we still haven't come up with a way to deal with the #include
> > > > mechanism in buildman. I've forgotten where it got to, or even what
> > > > the problem was?
> > >
> > > I assume this is related to the issue I filed? Among the problems are
> > > that buildman doesn't "know" about the architecture for example in time
> > > and so thinks everything is sandbox (since that's the default). That
> > > won't be an issue for your use case here (we have a number of defconfigs
> > > today that work around this issue by setting CONFIG_ARM=y and then a few
> > > other options too, so that the resulting build ends up correct).
> >
> > Yes...OK so I think I understand. If we are happy with the '#include'
> > scheme then I believe it would be easy enough to implement in
> > buildman. As Caleb mentions, it could likely run the pre-processor
> > first, or just process the #includes (which I prefer).
> >
> > Is the '#include' in defconfigs documented somewhere in Linux or
> > U-Boot? I really had no idea about this until you mentioned it.
>
> It should be documented somewhere too, yes. But you did review the
> original in 2027e99e61aa :)

Yes, although my question was never addressed [1]

Regards,
Simon

[1] https://patchwork.ozlabs.org/project/uboot/patch/20230829221457.101469-2-afd@ti.com/