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 <[email protected]> > wrote: > > > > > > > > On 27/10/2024 15:52, Simon Glass wrote: > > > Hi Tom, > > > > > > On Sun, 27 Oct 2024 at 00:33, Tom Rini <[email protected]> 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 <[email protected]> > > >>> --- > > >>> > > >>> 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
signature.asc
Description: PGP signature
