Tom Rini trini@konsulko.com writes:
On Fri, Mar 10, 2023 at 09:39:15PM -0800, Randy Dunlap wrote:
Hi--
On 3/10/23 18:37, Simon Glass wrote:
(I am sending this again to get more feedback)
In the case of Linux, only one build is produced so there is only a single configuration. For other projects, such as U-Boot and Zephyr, the same code is used to produce multiple builds, each with related (but different) options enabled.
This can be handled with the existing kconfig language, but it is quite verbose, somewhat tedious and very error-prone, since there is a lot of duplication. The result is hard to maintain.
Describe an extension to the Kconfig language to support easier handling of this use case.
Signed-off-by: Simon Glass sjg@chromium.org
IMO Masahiro has already answered this multiple times and I agree with his answers.
For others, the full previous thread is at https://lore.kernel.org/all/20230219145453.1.Idaaf79c3e768b85750d5a7eb732052...
So what level of interest is there in this?
Unlike Masahiro & co I am interested in generalizing Kconfig to be usable outside of the Linux kernel (for example, I've integrated it into the build2 build system[1]). However, in this case, I tend to agree with Randy and Masahiro: this feels like a very niche use-case (which I am still not 100% clear on, after reading the description 3 times) that would add quite a bit of complexity.
One thing that did cross my mind during those 3 reads is that maybe the essence of the feature you are looking for here is to be able to use a value from the previous phase as "initial" (i.e., stronger than Kconfig default but weaker than user-specified) when configuring the next phase. It probably won't allow you to solve your problem in an auto-magical way like your proposal, but perhaps you could get close enough while not complicating the Kconfig language significantly.
And as Simon asked in the thread, what about code refactoring that makes further maintenance easier?
From my experience, there is little interest in patches that make Kconfig
more general or improve the compatibility of the implementation. As a result, I am maintaining my patch set[2] out of tree.
[1] https://build2.org/libbuild2-kconfig/doc/build2-kconfig-manual.xhtml [2] https://github.com/build2-packaging/kconfig/tree/upstream-5.15-rc7