new way of writing defconfigs for freescale's powerpc platforms
Scott Wood
scottwood at freescale.com
Tue Apr 21 15:01:49 AEST 2015
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
More information about the Linuxppc-dev
mailing list