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

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 21 October 2016 at 21:40, Laszlo Ersek <lersek@redhat.com> wrote:
> On 10/21/16 22:19, Ard Biesheuvel wrote:
>> On 21 October 2016 at 21:14, Laszlo Ersek <lersek@redhat.com> wrote:
>>> On 10/21/16 21:58, Jordan Justen 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.
>>>
>>> I'm about to post a ~20-part series for OvmfPkg and ArmVirtPkg together
>>> that solves these BZs. :/ The DISABLE_NEW_DEPRECATED_INTERFACES feature
>>> test macro is already being used in three MdePkg library class header
>>> files (and a number of library instances), so I thought it was a done deal.
>>>
>>> I don't want to stifle the discussion of course, but at this point I
>>> think I will post the patches for review.
>>>
>>
>> Yes, please. Removing uses of deprecated interfaces is something we
>> should do anyway. What we shouldn't do is configure our platforms in
>> such a way that additional future deprecation automatically break the
>> build, unless we have a strong commitment from the other package
>> owners that they will ensure that this does not happen.
>>
>
> Well, my expectation is that the onus of keeping the tree working is on
> the patch submitter. Assume we adopt DISABLE_NEW_DEPRECATED_INTERFACES
> now (weaning ourselves off the functions that are *currently* disabled
> by the macro). Then whenever someone moves further functions under the
> scope of the macro -- thereby possibly breaking platform code --, it's
> going to be their responsibility to grep the tree for platform DSCs that
> enable DISABLE_NEW_DEPRECATED_INTERFACES, and either test-build those
> platforms reasonably extensively, or ask for help *in advance* (before
> committing the patches).
>
> For example, in the current work I'm about the post, I couldn't
> build-test everything (no RVCT over here, for example :)) Also I don't
> run Xen, so the Xen-related changes can't be functionally tested on my
> side -- but, I do ask for help with testing those. Same goes for the
> 32-bit ARM changes (which, it turns out, Michael and myself managed to
> fix separately, independently, and differently :))
>
> It's okay to modify code one can't build or test himself/herself, but
> then help should be asked for, and given too.
>
> TL;DR: the strong commitment you speak about is the default for any open
> source project, isn't it? ;)
>

Yes it is. But it should be made explicit.