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

[Andrew Fish <afish@apple.com>]

> On Oct 21, 2016, at 1:39 PM, Jordan Justen <jordan.l.justen@intel.com> 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.
> 

Jordan,

Well there should be a published plan for a future UDK that this change is going to happen before we "break it" in master. Publishing the plan with the UDK does not count :). 

>>   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! :)
> 

I think you make a very good point. How about DISABLE_2014_DEPRECATE_INTERFACES. I think that version scales, and might actually encourage cleanup as it shows when the interface first got deprecated. 

Thanks,

Andrew Fish

> -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 <https://lists.01.org/mailman/listinfo/edk2-devel>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel <https://lists.01.org/mailman/listinfo/edk2-devel>