Re: [edk2-devel] [PATCH V2 2/2] BaseTools: Factorize GCC flags

["Ard Biesheuvel" <ard.biesheuvel@arm.com>]

On 8/28/20 9:15 PM, Leif Lindholm wrote:
> On Fri, Aug 28, 2020 at 18:56:45 +0200, Laszlo Ersek wrote:
>>>> Leif, please comment!
>>>
>>> I did propose reverting it. But I asked for Ard's feedback on the
>>> reason for why we had the break in the flags-chain, in case he
>>> remembered (and he was on holiday at the time).
>>>
>>> Basically, I'm wondering whether we're better off changing this
>>> behaviour or simply nuking GCC48.
>>
>> I use GCC48 daily -- it's the system compiler on RHEL7. My laptop runs
>> RHEL7 -- I value stability above all.
> 
> That explains why it's still in then :)
> 
> OK, so then cleaning it up would be nice.
> 

Apologies, I had missed this discussion.

The reason the GCC flags are defined the way the are is because the 
GCC4x toolchains for x86 were completely disjoint from the UNIXGCC and 
other ones that were defined for ARM and IA64.

I agree that some cleanup would be nice, but if we are only going to 
reshuffle tools_def variable assignments, I'm not sure it is worth it. 
What I would like to see is a bit more structure, and some justification 
why we are using all those different options, as i am not convinced they 
are still needed even for GCC as far back as v4.8.

Also, even though I understand Laszlo's point about being able to use 
the RHEL 7 system compiler, using other toolchains is trivially easy 
with EDK2 (this is the whole point), and mainline EDK2 is arguably a 
development tree, not a stable production tree for ~5 year old firmware 
builds, and so I do think we should get rid of GCC48 even before RHEL7 
goes EOL.

I'd even go so far as suggesting that [at some point in the not too 
distant future], we rename GCC5 to GCCELFLTO (or something less 
obnoxious) and phase out all the version based GCC toolchains entirely. 
We might do the same for CLANG38 (the ELF based one), and depending on 
whether PE/COFF linker support ever materializes for ARM, have a single 
Clang+PE based toolchain as well.