[PATCH 10/19] buildman: Incorporate the genboardscfg.py tool

[Simon Glass]

Hi Tom,

On Wed, 13 Jul 2022 at 12:21, Tom Rini <trini at konsulko.com> wrote:
>
> On Wed, Jul 13, 2022 at 09:28:06AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 12 Jul 2022 at 15:38, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Mon, Jul 11, 2022 at 07:04:04PM -0600, Simon Glass wrote:
> > > > Bring this tool into buildman, so we don't have to run it separately. The
> > > > board.cfg file is still produced as part of the build, to save time when
> > > > doing another build in the same working directory. If it is out of date
> > > > with respect to the Kconfig, it is updated.
> > > >
> > > > Time to regenerate on a recent single-thread machine is 4.6s (1.3s on a
> > > > 32-thread machine), so we do need some sort of cache if we want buildman
> > > > to be useful on incremental builds. We could use Python's pickle format
> > > > but:
> > > >
> > > > - it seems useful to allow boards.cfg to be regenerated, at least for a
> > > >   while, in case other tools use it
> > > > - it is possible to grep the file easily, e.g. to find boards which use
> > > >   a particular SoC (similar to 'buildman -nv <soc>'
> > >
> > > While I don't think other tools still use boards.cfg, this will make it
> > > easier to find out that I'm wrong.  Perhaps once the CONFIG to Kconfig
> > > migration is done we can move to just pickle'ing the data or similar
> > > since I find the main use of what was in boards.cfg can be figured out
> > > with some other git grep'ing, and in turn that's mainly for me when
> > > trying to convert stuff.  Thanks for doing this.
> >
> > Yes. I'm excited to hear that Kconfig migration might be done - any
> > forecast as to when?
>
> Not yet.  I'm auditing CONFIG_SYS_* now, with a notion to move
> everything that's not really configurable just out of CONFIG namespace
> as the starting point.  That'll drop us down to ~500 to migrate, which
> feels a bit less daunting.
>
> > One thing we could to is provide an option for buildman to spit out
> > the various fields that go into boards.cfg
>
> Right.  So I might not have said this before, but one reason I wanted
> buildman to natively know kconfiglib and have everything was that while
> we can do a lot of good matching on what to build, it would be amazingly
> good to be able to say "build every platform with NVME_PCI set" (and if
> it's not too hard hex/int options with a specific value).

Ah OK. At present moveconfig has the functionality to list the boards
that have particular options (-b and -f). It is expensive to build the
database though - over a minute on a 32-thread machine. So we would
have to cache it. Also just about any change would invalidate the
cache and I'm not sure if it possible to detect which changes have no
effect on which cache entries...

Regards,
Simon