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