From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeroen Hofstee Date: Thu, 31 Jul 2014 23:06:19 +0200 Subject: [U-Boot] [PATCH v8 05/13] kconfig: switch to Kconfig In-Reply-To: <53DAAD40.8010204@wwwdotorg.org> References: <1406696905-25756-6-git-send-email-yamada.m@jp.panasonic.com> <53D97A31.30805@wwwdotorg.org> <20140731105640.5D19.AA925319@jp.panasonic.com> <53D9A502.2040700@wwwdotorg.org> <20140731203453.GV19374@bill-the-cat> <53DAAD40.8010204@wwwdotorg.org> Message-ID: <53DAAFCB.5000103@myspectrum.nl> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 31-07-14 22:55, Stephen Warren wrote: > On 07/31/2014 02:34 PM, Tom Rini wrote: >> On Wed, Jul 30, 2014 at 08:08:02PM -0600, Stephen Warren wrote: >>> On 07/30/2014 07:56 PM, Masahiro Yamada wrote: >>>> Hi Stephen, >>>> >>>> >>>> On Wed, 30 Jul 2014 17:05:21 -0600 >>>> Stephen Warren wrote: >>>> >>>>> On 07/29/2014 11:08 PM, Masahiro Yamada wrote: >>>>>> This commit enables Kconfig. >>>>>> Going forward, we use Kconfig for the board configuration. >>>>>> mkconfig will never be used. Nor will include/config.mk be >>>>>> generated. >>>>>> >>>>>> Kconfig must be adjusted for U-Boot because our situation is >>>>>> a little more complicated than Linux Kernel. >>>>>> We have to generate multiple boot images (Normal, SPL, TPL) >>>>>> from one source tree. >>>>>> Each image needs its own configuration input. >>>>>> >>>>>> Usage: >>>>>> >>>>>> Run "make _defconfig" to do the board configuration. >>>>> >>>>> This is quite unfortunate; it breaks any scripts that were >>>>> building U-Boot via "make _config; make". Can't we add >>>>> another rule to allow the old build commands to work? >>>> >>>> >>>> Technically, yes. I think we can. >>>> >>>> But I do not like having it permanently. >>>> >>>> >>>> So, we support both *_defconfig and *_config for a while (maybe 6 >>>> months or so?) >>>> and then remove *_config. >>>> >>>> Deal? >>> >>> If the old command-line is ever going to be removed, there's no point >>> supporting both at all; I'd have to hack my scripts to support both >>> sometime, so I may as well do it now rather than wait. >>> >>>>> Otherwise, I guess I'll have to hack my scripts to check whether >>>>> e.g. scripts/multiconfig.py (which was added in this commit) is >>>>> present in the tree, and execute different build commands based on >>>>> that... >>>> >>>> >>>> Do you mean, you need to build some different versions of U-boot ? >>> >>> Yes. I own some scripts that build U-Boot, and they need to work on any >>> reasonable version of U-Boot that anyone might want to build. For >>> example, they build 2014.07 just fine, and there's no reason they >>> should >>> ever stop being able to do that. I obviously also want my scripts to be >>> able to build any future version of U-Boot. >> >> So long as we have MAKEALL (and we'll have the discussion about moving >> to buildman sometime soon) this just becomes: >> if [ -x tools/genboardscfg.py ]; then >> tools/genboardscfg.py >> fi >> >> MAKEALL machine-name > > There's now a large disadvantage to MAKEALL; it takes longer to run > that to build U-Boot itself, since it must auto-generate boards.cfg. > Perhaps that's only done once, or when the data changes. > there is, it is _terribly_ slow when dealing with warnings in the build. MAKEALL is much better for that. Replacing the _config rule with _defconfig is just a bad idea afaic. Regards, Jeroen