Re: [edk2-devel] [PATCH 0/3] Arm builds on Visual Studio

["Liming Gao" <liming.gao@intel.com>]

Leif:

>-----Original Message-----
>From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Leif
>Lindholm
>Sent: Friday, September 20, 2019 4:27 AM
>To: Laszlo Ersek <lersek@redhat.com>
>Cc: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>; Baptiste
>Gerondeau <baptiste.gerondeau@linaro.org>; ard.biesheuvel@linaro.org;
>Kinney, Michael D <michael.d.kinney@intel.com>; Zhang, Shenglei
><shenglei.zhang@intel.com>
>Subject: Re: [edk2-devel] [PATCH 0/3] Arm builds on Visual Studio
>
>On Thu, Sep 19, 2019 at 09:24:15PM +0200, Laszlo Ersek wrote:
>> On 09/19/19 11:44, Leif Lindholm wrote:
>> > I agree with this as a general rule, but for this (hopefully never to
>> > be repeated) operation, it makes sense to me to keep each change in
>> > this set as one patch.
>> >
>> > For the simple reason that the alternative leaves several unusable
>> > commits in sequence in the repository. There is simply no way to
>> > bisect through this change on a per-package basis.
>> >
>> > This is after all a horrible horrible hack that lets us keep using the
>> > .asm files provided for one toolchain family (RVCT) in a different
>> > toolchain family (MSFT), without having to delete and re-add, losing
>> > history in the process.
>> >
>> > Would you be OK with an exception for this extremely unusual
>> > situation?
>>
>> (The question was posed to Liming, but I'm going to follow up here with
>> my own thoughts, after getting CC'd by Liming. Thanks for that BTW.)
>
>Yes, I should have thought of that myself - Baptiste did exactly what
>I asked him to.
>
>> Let's assume the changes are split up with a fine granularity. Under
>> that assumption, consider two cases:
>>
>> (1) ARM builds on Visual Studio are broken until the last patch is
>> applied, but all other toolchains continue working fine throughout the
>> series.
>>
>> versus
>>
>> (2) ARM builds are broken on Visual Studio *and* on at least one other
>> -- preexistent -- toolchain, until the last patch in the series is applied.
>>
>>
>> Which case reflects reality?
>>
>> If it's case (1), then I prefer the fine-grained patch series structure.
>> Nothing regresses with existent toolchains (so bisection works with
>> them), we just have to advertise the last patch in the series as the one
>> that enables Visual Studio.
>>
>> If it's case (2), then I agree with the larger (multi-package) patch, as
>> a rare exception.
>>
>> (We can also put it like this: if it's *possible* to write this series
>> such that it enables (1), then we should strive for that.)
>
>I agree with your logic.
>It's just that I'm not even aware of anyone who has *tried* building
>with RVCT for several years. So we leave the "probably not working"
>toolchain potentially working for a few more commits, as a tradeoff
>against enabling the new one in one go.
>
>(Now, fair, there are other issues with the VS ARM port that as per
>the cover letter will also need to be addressed before the port is
>fully functional.)
>
If RVCT doesn't work, this change will follow into case (1). Right? 

Thanks
Liming
>/
>    Leif
>
>