Hi,
On Sun, 16 Jul 2023 at 09:12, Tom Rini trini@konsulko.com wrote:
On Sat, Jul 15, 2023 at 05:40:35PM -0600, Simon Glass wrote:
Hi Tom,
On Thu, 13 Jul 2023 at 16:54, Tom Rini trini@konsulko.com wrote:
On Wed, Jul 12, 2023 at 08:00:28AM -0600, Simon Glass wrote:
Hi Jason,
On Tue, 11 Jul 2023 at 16:29, Jason Kacines j-kacines@ti.com wrote:
Add support to config fragments (.config) located in the /board directory. This will allow only base defconfigs to live in /configs and
Does this mean defconfigs?
This looks like it would cover defconfig files too, but the initial motivation is config fragments. See https://patchwork.ozlabs.org/project/uboot/patch/20230606071850.270001-5-cla... for another example.
all fragments to live in their respective device directory in /board/..
Why do we want this? The patch should have a motivation.
I've asked a few people to look in to this because we have a lot of cases today of N _defconfig files where we could really instead have 1 _defconfig file and N config fragment files. But I do not want them living in the top level configs directory as that will get even more unmanageable.
OK I see, thank you. The patch still needs this motivation though.
So you're saying you want the message re-worded?
Yes, to explain why.
Could we also get some docs in doc/build/gcc.rst or similar?
What's not in this patch (and not an ask at this point) is figuring out how buildman could handle "foo_defconfig bar.config" as the required config target.
Indeed. Also, should they appear in the boards.cfg list?
I doubt it? I'm not sure yet how we address getting buildman to know about valid additional combinations. Take the example of something like: som_vendor_carrier_defconfig + som_vendor_imx7_som.config + emmc_boot_instead.config + customer_production_tweaks.config
How would you want buildman to know about that? Does it even really need to, on the other hand? And that's not I think an uncommon example, it's just splitting colibri_imx7_emmc_defconfig in to how it would be used by someone taking that carrier+som to production, with their own touchscreen and a few other tweaks in the dtb that needs to be passed to linux. Or the mnt reform with whatever SOM/COM you happen to have for it.
Well firstly we should only worry about things that are in-tree.
The thing is, if we don't validate that the configs at least build, then someone could change a config (anywhere in Kconfig or in a 'base' defconfig) and break the build for these 'add-on' configs. Also if there is no record of what fragments can be built with what, it could get awfully confusing.
I would suggest an interface where you can query which fragments are available for a board, and that buildman support building them. For that to work, we need some sort of structure. For example the config fragment could have a line listing the defconfig / .config filename it is intended to augment.
Regards, Simon