[PATCH v2] sandbox: Add a build without CMDLINE

[Simon Glass]

Hi Caleb, Tom,

On Mon, 28 Oct 2024 at 22:54, Caleb Connolly <caleb.connolly at linaro.org> wrote:
>
>
>
> On 27/10/2024 15:52, 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?
>
> qcm6490_defconfig needs to re-define CONFIG_ARM=y for buildman to be happy.
>
> Why is buildman looking at the defconfig anyway? Maybe it could just run
> the pre-processor first?

It could, but I really want buildman to understand things. If we can
say that '#include' in the file is the only thing it needs to deal
with, then I believe we can update Kconfiglib to deal with it, or
perhaps preprocess the file. That uncertainty (as to what the 'spec'
actually is) is what has held me back from looking at it too
seriously.

Regards,
Simon