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

["Gao, Liming" <liming.gao@intel.com>]

Laszlo and Leif:
  PCD value are the position relation. In DSC file, the latter one will override the first one. But, PCD type can't be overridden. For example, if PCD is listed in [PcdsFixedAtBuild] section in the config.inc, PCD can't be listed in [PcdsPatchableInModule] section in Platform.dsc. I think Platform may not only override PCD value, but also override PCD type. To meet with platform requirement, we had better not place PCD setting in common DSC file. 

Thanks
Liming
>-----Original Message-----
>From: Leif Lindholm [mailto:leif.lindholm@linaro.org]
>Sent: Sunday, September 24, 2017 12:58 AM
>To: Laszlo Ersek <lersek@redhat.com>
>Cc: edk2-devel@lists.01.org; Kinney, Michael D
><michael.d.kinney@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>;
>Andrew Fish <afish@apple.com>; Ard Biesheuvel
><ard.biesheuvel@linaro.org>; Gao, Liming <liming.gao@intel.com>; Zhu,
>Yonghong <yonghong.zhu@intel.com>
>Subject: Re: [edk2] [RFC 0/6] Create central repository for boilerplate
>configuration
>
>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