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 <ler...@redhat.com> >Cc: devel@edk2.groups.io; Gao, Liming <liming....@intel.com>; Baptiste >Gerondeau <baptiste.gerond...@linaro.org>; ard.biesheu...@linaro.org; >Kinney, Michael D <michael.d.kin...@intel.com>; Zhang, Shenglei ><shenglei.zh...@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 > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#47886): https://edk2.groups.io/g/devel/message/47886 Mute This Topic: https://groups.io/mt/34187297/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-