From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ismael Luceno Cortes <ismael.luceno@silicon-gears.com>
Date: Thu, 7 Mar 2019 14:47:23 +0000
Subject: [U-Boot] [PATCH 6/6] ARM: rmobile: Sync Gen3 defconfigs
In-Reply-To: <CAK7LNATEauLfypgMoHkUmgdCSWHpHzfSXd4VdTzww3Z9cnRxAg@mail.gmail.com>
References: <20190218130541.22671-1-marek.vasut+renesas@gmail.com>
 <20190218130541.22671-6-marek.vasut+renesas@gmail.com>
 <CAH3KO=0j=ckSM73k4rm-CZ_EKpWcA3j4UePrzodz59KpLPtADQ@mail.gmail.com>
 <51dd743c-6b0b-1922-c9c0-949176faca8e@gmail.com>
 <20190304234031.GA12143@vmlxhi-102.adit-jv.com>
 <CAK7LNATEauLfypgMoHkUmgdCSWHpHzfSXd4VdTzww3Z9cnRxAg@mail.gmail.com>
Message-ID: <20190307144723.GC8143@kiki>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On 07/Mar/2019 22:54, Masahiro Yamada wrote:
<...>
> Each defconfig supports multiple boards
> by using a different DEVICE_TREE.
> 
> If you are interested, doc/README.uniphier
> explains it supports much more boards than defconfig.
> 
> The drawback of this ways will increase the image size
> since it needs to compile-in all necessary
> boot-code and drivers.
> So, this solution only works when you have enough
> memory footprint.
> 
> 
> > >
> > > I'd still like to be able to do "make soc_board_defconfig ; make"
> > > without having to rack my brain which other .cfg files I need to append.
> > > I didn't find a good solution for this however. Do you know of one ?
> 
> One idea might be,
> to hack scripts/kconfig/Makefile
> to allow a defconfig to contain shell scripts.
> 
> 
> For example, r8a7795_salvator-x_defconfig will look like:
> 
>   #!/bin/sh
>   $MAKE r8a7795_defconfig
>   $MAKE r8a7795_salvator-x.config
> 
> 
> Makefile will run it if the first line is shebang,
> otherwise handle it as a normal defconfig.
> 
> 
> I am not so sure if this is the right thing to do.
> So, it should be discussed widely anyway if we try to
> introduce something new.
> 
> A problem in this way is, as Eugeniu pointed out,
> we have no way to sync .config fragment files.
> 
> 
> > I think we have proper tools to track the correctness of the defconfig
> > files (i.e. savedefconfig Kbuild target), but we don't seem to have
> > proper tools to validate configuration fragments. So, I agree the
> > contents of the fragments would potentially go wild. I think having
> > either a built-in Kbuild/Kconfig procedure or some scripted way to keep
> > the fragments under control would greatly increase the confidence in
> > using them, but I am unaware of such.
> 
> You are right.
> 
> We will need something like savedefconfig for .config files,
> but we do not have a good tool. At least, I do not know.

Perhaps a simpler solution would be to add support for some sort of
selection mechanism. E.g.:

family_defconfig:

	A=y if (SOC in {"A", "B", "C"})

board_A.config:

	SOC="C"

So that .config files can contain only simple meta-data; and both things
would be easy to validate.

There's a little impedance mismatch here and there, but it could work,
and the needed effort seems reasonable.