[PATCH v2] sandbox: Add a build without CMDLINE

[Tom Rini]

On Fri, Nov 01, 2024 at 04:37:17PM +0100, Simon Glass wrote:
> 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.

Given https://github.com/llvm/llvm-project/issues/78778 I do not like
preprocessing the files. I want to stress that
scripts/kconfig/merge_config.sh is the canonical way to merge fragments.
So if taking the Kconfiglib approach, implementing the above but in
python would be good (and we can suggest that #include be the normal way
one file says to use other fragments but not let us be blocked on making
this better).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241101/338fc43c/attachment.sig>