Re: [Bug 164] Add the build option "/D DISABLE_NEW_DEPRECATED_INTERFACES" in package DSC files

[Jordan Justen <jordan.l.justen@intel.com>]

On 2016-10-21 14:02:44, Laszlo Ersek wrote:
> On 10/21/16 22:39, Jordan Justen wrote:
> > On 2016-10-21 13:20:49, Andrew Fish wrote:
> >>    Thus the option is to DISABLE_DEPRECATED_INTERFACES as that maintains
> >>    backward compatibility.
> > 
> > In order to support UDK releases, maybe ENABLE_UDK2014_INTERFACES would be
> > something to consider. Or ENABLE_UDK_INTERFACE=2014 so we can use <=.
> > 
> > But, I still think that EDK II platforms (as a goal) should represent
> > the best, cleanest examples of using EDK II. And, I think having every
> > platform accumulate cruft like CFLAGS to disable deprecated interfaces
> > works against that goal.
> > 
> > Another point. What about when we want to deprecate more interfaces?
> > Oh know, we better not break platforms that only specified
> > DISABLE_NEW_DEPRECATED_INTERFACES! Let's add
> > DISABLE_NEW_DEPRECATED_INTERFACES2! :)
> 
> Honestly, I imagined that DISABLE_NEW_DEPRECATED_INTERFACES would be
> temporary in the edk2 tree. That is, it's a means so we can gradually
> transition with all the in-tree stuff to a deprecationless code base.
> Once that's done -- i.e., *all* platform DSCs within the edk2 tree
> specify this feature test macro under their respective [BuildOptions]
> sections --, then whatever the macro excises from the core packages can
> be removed permanently, together with those platform [BuildOptions].
>

That could be reasonable, although I'd argue that we could flip it
around. Opt-in to the deprecated interfaces on all platforms, and then
start marking deprecated interfaces. Finally we could clean up
platforms and removed the override.

But ... I think DISABLE_NEW_DEPRECATED_INTERFACES was first added in:

commit bf4a3dbd4751b6411bdfc98bf3ac2c4f928bdfdf
Author: ydong10 <ydong10@6f19259b-4bc3-4df7-8a09-765794883524>
Date:   Wed May 30 07:36:00 2012 +0000

So, I guess it is not going to be removed anytime soon. :(

-Jordan

> I think this should prevent the accumulation of cruft in edk2. Yes,
> downstreams will have to catch up (or use UDK for a while longer). If
> that's inconvenient, I have a solution: upstream your codebase, and then
> the community will take care of keeping it in sync with the rest ;)
> 
> (This is the standard Linux suggestion BTW, not my idea.)
> 
> NB, we're not talking about protocols or PPIs (they're ABI); this is
> about (statically linked) edk2-only libraries.
> 
> Thanks!
> Laszlo