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@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@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@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).