From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754831AbcGHLs2 (ORCPT ); Fri, 8 Jul 2016 07:48:28 -0400 Received: from mout.kundenserver.de ([212.227.126.134]:56370 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754944AbcGHLrt (ORCPT ); Fri, 8 Jul 2016 07:47:49 -0400 From: Arnd Bergmann To: Masahiro Yamada Cc: Michal Marek , "Yann E. MORIN" , Josh Triplett , Darren Hart , Linux Kbuild mailing list , kernel-build-reports@lists.linaro.org, Michal Marek , Thiago Macieira , Linux Kernel Mailing List Subject: Re: [PATCH] [RFC] Kbuild: avoid "make tinyconfig" warnings Date: Fri, 08 Jul 2016 13:50:36 +0200 Message-ID: <4257104.nQPxdqsVCl@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-22-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: References: <20160704142608.2069991-1-arnd@arndb.de> <5717639.GLOFncF6tL@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:fLQManwzckQH7wfCTwHUxSL4raiuxLuFWqWHPt4CQcFh2RoDzm8 ziX+WD0AiuuGb18kLO8e3jMLOnu7eMCyDYI0cgo6Vz1QCIYpMdVvJ+cuSCmb7342XvH1/pQ /67KlZR0oD+HN+K5TJA62Rq2znoeHGi1+wBzWrvc8WyDnBpi+XyLKRm4FVmVe1tduYvqyx+ 3Z49u+P3pIOWQYB4fRdzw== X-UI-Out-Filterresults: notjunk:1;V01:K0:a3ZftAouCBY=:zoSbO5ttk6+XG9W7jU5tfr PWL0AQe2KgXg4RK7cLMqLkzOgf4TGxa9/xYOK9XDU3jGYuxPeZCj+aIZlHVgRXOylLTE4ROTk cf3z17+4VHcLiFBK/DD75vZUA6GkSwt/3D1aF7bMgkM98JQcPL3oSbDGl0cWj2oJ/bXcHSS1F t8bBw3MucdpO6ENHcSNuaPu3TSjKPzqQKvAlRCtcJMPB5kB/h+afOXclnWPKd022Op30XRHaM J8dnPlFeAOK1tsbtoh7Ixz2k7bKCjpmRyoQp4Hiv8XvzmzVQbA7oTfg7pIuCxKhap+SbpYWCN nYQ6abe/VpuhHoCYBk6wHwnBZbzDnNBBeuSdG1Z3HK4myjRcKjN4y4YlZpGDQjhV9odDUWhgY Y0w813km2oxLfHKC0YwOxucENuQXc6LVKIvLGTvuwISpTvSAd/9TKyATNT0h5CM+fuulTu4tf Tq4aCTd6SXeh1au+lRStpCv5lTxo1i/ntnKSJSAU2ixahpSW9tlWmoj55cSI6bwhZ36zao+uH GE/A3SzwVoc+NR67cKkFQTHi944xLLE6XozevLXu6h6jGNGKaxUqchivzGNPHuu8yeAF5mxLD fNkfxJB3oG6GefrBWY4Bhgru45ELPXXq/zxKtZB7VVX5Ox5cftnfMMnzYTZettYHkFuS06n2U SM9NG3jrTtYZPnfhOe9VX/opZTlUVljGfbcTHneBg3rNFTI8M+iyNGaoNhn27g2nIwgqNQt4V mhyCEdxeM92YaY8l Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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