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 _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
