On Friday, July 8, 2016 10:41:57 AM CEST Masahiro Yamada wrote:
2016-07-06 22:49 GMT+09:00 Arnd Bergmann arnd@arndb.de:
It is already specified by:
allnoconfig allyesconfig allmodconfig alldefconfig randconfig: $(obj)/conf $< --$@ $(Kconfig)
I don't see that yet. How does this line provide the dependency?
"make tinyconfig" works like this:
This means, run "make allnoconfig", then "make tiny.config" in this order.
Ok, got it, sorry for being slow here.
So, let's ignore my incorrect patch for the moment. Do you have any other idea for how to avoid the warning?
Of your four ideas, I do not like the first two, but the others sound reasonable.
ok
- merge the fragments first and then use the combined fragment as the KCONFIG_ALLCONFIG file.
This is a strait-forward solution. I thought of this one, too.
- change merge_config.sh to do a 'savedefconfig' step before applying the fragment, so it doesn't warn about choice statements that are overridden from their default, as opposed to having conflicting choices.
This sounds interesting.
BTW, I have been wondering if we could support merge_config as a native feature of Kconfig instead of by a separate shell script.
If we could support KCONFIG_ALLCONFIG for "make oldconfig" perhaps merge_config.sh will go away? Maybe I am missing something, though.
I agree this sounds really nice, but I see two problems with it:
- at the moment, we always read exactly one input file from the kconfig tool, and that can be one of .config arch/${ARCH}/defconfig arch/${ARCH}/configs/*_defconfig the KCONFIG_ALLCONFIG contents ./all{no,yes,mod,def,random}.config Teaching the tool to have two input files basically means reimplementing merge_config.sh in C. Definitely doable, and probably nicer than what we have, but not trivial. - It doesn't actually solve the problem of the warnings that I'm trying to address, that would still have to be done on top of the reimplementation.
Arnd