Tom Rini <trini@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> > > > > 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.Idaaf79c3e768b85750d5a7eb732052576c5e07e5@changeid/ > > 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
