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

[Laszlo Ersek <lersek@redhat.com>]

On 10/21/16 22:39, Jordan Justen wrote:
> On 2016-10-21 13:20:49, Andrew Fish wrote:
>>      On Oct 21, 2016, at 12:58 PM, Jordan Justen <jordan.l.justen@intel.com>
>>      wrote:
>>      On 2016-10-21 12:37:21, Ard Biesheuvel wrote:
>>
>>        I don't remember seeing any discussion regarding
>>        DISABLE_NEW_DEPRECATED_INTERFACES on the list, so I am a bit surprised
>>        seeing these bugs being filed and assigned.
>>
>>      I agree.
>>
>>      Also, the terminology seems confusing. 'new deprecated' seems like a
>>      contradiction. I guess it means 'newly deprecated', but that seems
>>      like a term that is quickly going to become obsolete. Soon there will
>>      be old deprecated items that are disabled with this switch.
>>      DISABLE_DEPRECATED_INTERFACES sounds better.
>>
>>      But, shouldn't we have platforms opt-in to using the deprecated
>>      interfaces rather than adding DISABLE_NEW_DEPRECATED_INTERFACES to the
>>      build command line for every EDK II platform?
>>
>>      Not using deprecated items should be the default for EDK II platforms.
>>      If a platform has to opt-in to the deprecated content in their .dsc,
>>      then it is obvious that they are relying on deprecated functionality.
>>
>>      So, I guess I'd propose adding ENABLE_DEPRECATED_INTERFACES instead.
>>
>>    Jordan,
>>    I think it depends on your point of view. If you have a platform that
>>    works and you update the edk2 revision you would expect it to still work.
> 
> I think this is what UDK is for. If you want to depend directly on EDK
> II, then you'll see less stability.
> 
>>    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].

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

> 
> -Jordan
> 
>>    I think it makes total sense to turn on DISABLE_DEPRECATED_INTERFACES on
>>    all the open source edk2 platform as soon as possible so all the open
>>    source code is following current best practices.
>>    Not to mention it would probably be a really good idea to give all the
>>    downstream folks a long lead time about the plan of making a non backward
>>    compatible change. 
>>    Thanks,
>>    Andrew Fish
>>
>>      -Jordan
>>
>>        Before making any such changes, I would like a strong commitment from
>>        other package owners that deprecating an interface brings along with
>>        it the responsibility to update all existing callers, otherwise
>>        setting this define will only result in more breakage, and ARM has
>>        seen its share of inadvertent breakage in the past when changes to
>>        core code were made without taking other architectures into account.
>>
>>        On 21 October 2016 at 02:21,  <bugzilla-daemon@bugzilla.tianocore.org>
>>        wrote:
>>
>>          https://bugzilla.tianocore.org/show_bug.cgi?id=164
>>
>>          yonghong.zhu@intel.com changed:
>>
>>                    What    |Removed                     |Added
>>          ----------------------------------------------------------------------------
>>                    Priority|Lowest                      |Normal
>>                      Status|UNCONFIRMED                 |CONFIRMED
>>                    Assignee|michael.d.kinney@intel.com
>>           |ard.biesheuvel@linaro.org
>>              Ever confirmed|0                           |1
>>              Release(s) the|                            |EDK II Trunk
>>              issues must be|                            |
>>                       fixed|                            |
>>
>>          --- Comment #1 from yonghong.zhu@intel.com ---
>>          Assign to Package owner.
>>
>>          --
>>          You are receiving this mail because:
>>          You are the assignee for the bug.
>>
>>        _______________________________________________
>>        edk2-devel mailing list
>>        edk2-devel@lists.01.org
>>        https://lists.01.org/mailman/listinfo/edk2-devel