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

["Leif Lindholm" <leif.lindholm@linaro.org>]

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.)

/
    Leif