Re: new way of writing defconfigs for freescale's powerpc platforms

[Scott Wood <scottwood@freescale.com>]

On Mon, 2015-04-20 at 22:42 -0500, Timur Tabi wrote:
> Scott Wood wrote:
> >> >
> >> >Why do you need a powerpc-specific way to use merge_config.sh?  Other
> >> >architectures have the same problem with defconfigs.
> 
> > What are you perceiving as "powerpc-specific" about what we're
> > proposing?
> 
> Well, there's the subject of this thread, which is "new way of writing 
> defconfigs for freescale's powerpc platforms".
> 
>  > Are you complaining about the actual content of which
> > fragments to use to produce which defconfigs going in arch/powerpc?
> 
> No, I'm just trying to figure out what's powerpc-specific about Lijun's 
> proposal.

The set of defconfigs that we're talking about refactoring to use this
mechanism.

> >> >Besides, wouldn't it make more sense to define a new defconfig type,
> >> >like p1_defconfig.merge, and if you do "make p1_defconfig.merge" it
> >> >knows to call merge_config.sh?
> 
> > That's already there.  "make <foo>.config".
> 
> Ok, so I'm definitely confused now.  I have no idea what's actually 
> being proposed, since apparently the ability to have merge configs 
> already exists.

The proposal is that we make use of that mechanism.

> Wouldn't it just be simpler to pass multiple defconfigs to 'make', and 
> then 'make' will know to call merge_config.sh on them?  So instead of
> 
> make ./scripts/kconfig/merge_config.sh 
> arch/powerpc/configs/fsl_basic_config p1_defconfig
> make
> 
> we can just do
> 
> make fsl_basic_config p1_defconfig
> make

We want single-name config targets to still work from the user's
perspective, but we want to reduce the (often imperfect) duplication
under the hood.

-Scott