[lkml]   [2016]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] [RFC] Kbuild: avoid "make tinyconfig" warnings
On Friday, July 8, 2016 10:41:57 AM CEST Masahiro Yamada wrote: 
> 2016-07-06 22:49 GMT+09:00 Arnd Bergmann <>:
> >> 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.


> > - merge the fragments first and then use the combined fragment as the
> This is a strait-forward solution.
> I thought of this one, too.
> > - change 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 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
Teaching the tool to have two input files basically means reimplementing 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.


 \ /
  Last update: 2016-07-08 14:21    [W:0.054 / U:3.788 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site