Re: [RFC 0/6] Create central repository for boilerplate configuration

[Leif Lindholm <leif.lindholm@linaro.org>]

On Fri, Sep 22, 2017 at 01:20:57PM +0200, Laszlo Ersek wrote:
> On 09/20/17 23:09, Leif Lindholm wrote:
> > On Wed, Sep 20, 2017 at 08:14:59PM +0200, Laszlo Ersek wrote:
> 
> >> (2) Replacing a build define called FOOBAR with CONFIG_FOOBAR will break
> >> all downstream build scripts. Is the CONFIG_ prefix a requirement?
> > 
> > It was explicitly intended to break compatibility, to ensure we didn't
> > end up with things accidentally working until something unrelated
> > changed in the future.
> 
> Interesting idea. I guess we could try to reach out to all of the
> "repeat builders" of OVMF.

The proposal to drive the CONFIG options as Pcds would also be a
solution to this issue.

> >> (3) I think PCDs should not be included in ConfigPkg DSC include files,
> >> even if several platforms set the same value. The set of libraries and
> >> driver modules commonly used for a given feature is mostly constant
> >> across platforms (and it is easy to extend, incrementally); but I don't
> >> think the same holds for PCDs. Especially if a user wants to change a
> >> PCD for one platform but not the other. Even if repeated settings for a
> >> PCD worked (all on the same level of "specificity"), I'd find the result
> >> confusing.
> > 
> > Also a subject for discussion.
> > My intent was that if most of the open source platforms had an
> > override on the default of a particular Pcd, we could override it in
> > the config fragments without changing the .dec (and affecting
> > non-public ports).
> 
> Right, that's great...
> 
> > Individual platforms can still override (again).
> 
> ... but this "again" part is what confuses me (assuming it would
> technically work). We'd have a PCD default in the .dec, then a setting
> in the central .dsc.inc that ultimately qualifies as a platform-level
> setting, and finally a setting in the actual platform .dsc, which *also*
> qualifies as a platform-level setting. IOW, one in the .dec, and two in
> the (final) .dsc.

Yes. But I cannot think of another way of handling it, that does not
also mean stuffing a lot of boiler plate back into the platform-level
files.

> I have no clue if this works, but even if it does, the priority could
> depend on the order of inclusion, which I find confusing.

Oh, definitely. But also under complete control of the platform.

Potentially, if this becomes some great success story, we will want to
extend the build command with a separate [includes] section to give
greater control over enforcing order.

> Liming, Yonghong, can you guys please comment on this?

Yes, please :)

Regards,

Leif