Re: 回复: [edk2-devel] [PATCH v2 00/13] BaseTools,CryptoPkg,MdePkg,OvmfPkg: Delete CLANG35,CLANG38,GCC48,GCC49, rename GCC5 to GCC, update CLANGDWARF, delete VS 2008-2013, EBC

["Rebecca Cran" <rebecca@bsdio.com>]

On 4/3/23 6:15 AM, Leif Lindholm wrote:
> On Mon, Apr 03, 2023 at 13:55:19 +0200, Ard Biesheuvel wrote:
>> I agree that we should either support a toolchain (and have CI
>> coverage for it) or not, in which case we should just remove it.
>>
>> However, the issues being reported are specific to SEV-SNP and TDX,
>> which implies that they are specific to OVMF. And actually, the
>> reported issue at
>>
>> OvmfPkg/Library/CcExitLib/CcExitVcHandler.c:1358:10:
>> error: ‘XCr0’ may be used uninitialized [-Werror=maybe-uninitialized]
>>
>> seems to be a valid concern.
>>
>> So the point I am making is that OVMF gets a lot of attention in the
>> open source project, but in the wider ecosystem, there are many
>> platforms relying on this code base that don't incorporate the Coco
>> components at all, so whether OVMF currently builds with GCC49 is not
>> 100% relevant.
>>
>> So I am leaning towards retaining GCC49 as GCCNOLTO, and getting some
>> coverage for it in CI, as we occasionally get useful diagnostics out
>> of it. But I am not going to fight any battles over it - I rarely use
>> it myself, and so I will not miss it when it's gone.
> I agree with all aspects of this statement. I would *prefer* to keep
> it as a canary - with CI.

Given it's catching issues, I'd like to keep it too.

In terms of CI coverage, I'd like to have both gcc 6 and gcc 12 running 
GCC and GCCNOLTO builds: we've already broken gcc 5 compatibility by 
introducing GoogleTest (which uses nullptr), so by doing builds with gcc 
6 we'll be able to know when we break it and update 
tools_def.txt.template with a note that we'll subsequently require gcc 7.

Similarly, we should also add CLANGPDB and CLANGDWARF builds.


I suspect we'll rapidly run into scaling issues though, since GitHub 
Actions has a limit of 20 concurrent jobs on the free plan 
(https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration), 
and in order to keep CI times reasonable we'll probably want many more 
tasks to be running in parallel. There's a beta 'larger runners' feature 
(https://docs.github.com/en/actions/using-github-hosted-runners/using-larger-runners), 
but I'm wondering if we might want to scale using something like Azure 
or EC2 (https://github.com/machulav/ec2-github-runner) instead, if the 
costs aren't going to be prohibitive?


-- 

Rebecca Cran