Hi Tom, On Fri, 1 Nov 2024 at 17:26, Tom Rini <tr...@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 <tr...@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 <tr...@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 <s...@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-...@ti.com/