Config fragments

[Heinrich Schuchardt]

On 23.08.23 17:30, Simon Glass wrote:
> Hi,
> 
> Up until 2023.04 it has been possible to build all the defconfigs but
> with 2023.07 that changed. Tom mentioned this to me recently.

Could you, please, explain why there are defconfig that can't be built. 
The CI should have thrown an error in this case.

Why don't we delete defconfigs that don't build?

> 
> Up until 2023.04 we can enumerate all the board configs that can be
> built. We can build any of them using a single name and a single
> defconfig. The boards.cfg file which buildman creates contains a full
> list of things that can be built.
> 
>  From 2023.07 this changes and we now have random .config files
> sprinkled about the place. I say random because they are not connected
> to anything. For example, here is
> board/ti/am62x/MAINTAINERS:
> 
> AM62x BOARD
> M: Dave Gerlach <d-gerlach at ti.com>
> M: Tom Rini <trini at konsulko.com>
> S: Maintained
> F: board/ti/am62x/
> F: include/configs/am62x_evm.h
> F: configs/am62x_evm_r5_defconfig
> F: configs/am62x_evm_a53_defconfig
> 
> BEAGLEPLAY BOARD
> M:     Nishanth Menon <nm at ti.com>
> M:     Robert Nelson <robertcnelson at gmail.com>
> M:     Tom Rini <trini at konsulko.com>
> S:     Maintained
> N:     beagleplay
> 
> In most cases the MAINTAINERS file tells us about each board and until
> [1] I had assumed that was the case. With that patch reverted, these
> are the only 'orphaned' MAINTAINERS entries (buildman
> --maintainer-check):
> 
> WARNING: orphaned defconfig in board/armltd/vexpress64/MAINTAINERS
> ending at line 8
> WARNING: orphaned defconfig in board/google/veyron/MAINTAINERS ending at line 44
> WARNING: orphaned defconfig in
> board/mikrotik/crs3xx-98dx3236/MAINTAINERS ending at line 7
> WARNING: orphaned defconfig in board/st/common/MAINTAINERS ending at line 6
> WARNING: orphaned defconfig in board/ti/am62x/MAINTAINERS ending at line 15

Why should we care about the maintainer status when building a defconfig?

> 
> But Tom advised me that MAINTAINERS is not intended for this purpose,

Enumerating configs/*defconfig would make more sense to me.

Best regards

Heinrich

> so the check has been dropped. I am not suggesting we bring it back,
> necessarily, but if we did, we could use it to specify the .config and
> defconfig files which are used by each board.
> 
> *Failing that*, I suggest a new 'name.brd' file in the board directory
> to contain this information, e.g.
> 
> # Contents of board/ti/am62x/beagleplay.brd:
> beagleplay-r5: am62x_evm_r5_defconfig beagleplay_r5.config
> beagleplay-a53: am62x_evm_a53_defconfig beagleplay_a53.config
> 
> This could be parsed by buildman and other tools, to produce a list of
> available boards and to build each using a single name (e.g. make
> beagleplay-r5_defconfig)
> 
> What do people think?
> 
> Regards,
> Simon
> 
> [1] https://patchwork.ozlabs.org/project/uboot/patch/20230803185144.1760729-2-sjg@chromium.org/