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

["gaoliming" <gaoliming@byosoft.com.cn>]

Ard:

> -----邮件原件-----
> 发件人: bounce+27952+64834+4905953+8761045@groups.io
> <bounce+27952+64834+4905953+8761045@groups.io> 代表 Ard
> Biesheuvel
> 发送时间: 2020年8月31日 21:22
> 收件人: Leif Lindholm <leif@nuviainc.com>; Laszlo Ersek
> <lersek@redhat.com>
> 抄送: Pierre Gondois <Pierre.Gondois@arm.com>; devel@edk2.groups.io;
> bob.c.feng@intel.com; liming.gao@intel.com; Tomas Pilar
> <Tomas.Pilar@arm.com>; nd <nd@arm.com>
> 主题: Re: [edk2-devel] [PATCH V2 2/2] BaseTools: Factorize GCC flags
> 
> 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 have the same feeling on VS tool chain. Now, very old VS2008 tool chain is still in tools_def.txt.

> 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.
> 
This is a good idea to unify tool chain. But, the impact is big. 
To keep combability, GCC5 and GCCELFLTO can be defined together and share the same setting. 

Thanks
Liming
> 
>