On Wed, May 29, 2013 at 3:23 AM, Olivier Martin <olivier.mar...@arm.com> wrote: > I do not see any issue to add this support to GCC4* except I do not really > like the hardcoded path in the compiler name (eg: GCC44_IA32_PREFIX, > GCC44_X64_PREFIX). I understand removing the architecture from the > CROSS_COMPILE/TOOLS_PFX variable name would prevent to use `build -a ARM -a > IA32 -a X64 -p MdePkg/MdePkg.dsc -t GCC`; but I am not sure many people > build for all the architectures at the same time. Again, this cross compiler > is mainly to ease the use of EDK2 build system. > If people still want to build for many architectures they can call the > 'build' command line for each of those architecture. > > Instead of that: > *_GCC44_IA32_OBJCOPY_PATH = DEF(GCC44_IA32_PREFIX)objcopy > *_GCC44_IA32_CC_PATH = DEF(GCC44_IA32_PREFIX)gcc > *_GCC44_IA32_SLINK_PATH = DEF(GCC44_IA32_PREFIX)ar > *_GCC44_IA32_DLINK_PATH = DEF(GCC44_IA32_PREFIX)ld > *_GCC44_IA32_ASLDLINK_PATH = DEF(GCC44_IA32_PREFIX)ld > *_GCC44_IA32_ASM_PATH = DEF(GCC44_IA32_PREFIX)gcc > *_GCC44_IA32_PP_PATH = DEF(GCC44_IA32_PREFIX)gcc > *_GCC44_IA32_VFRPP_PATH = DEF(GCC44_IA32_PREFIX)gcc > *_GCC44_IA32_ASLCC_PATH = DEF(GCC44_IA32_PREFIX)gcc > *_GCC44_IA32_ASLPP_PATH = DEF(GCC44_IA32_PREFIX)gcc > *_GCC44_IA32_RC_PATH = DEF(GCC44_IA32_PREFIX)objcopy > > I would prefer to have something like that: > *_GCC44_*_OBJCOPY_PATH = ENV(CROSS_COMPILE)objcopy > *_GCC44_*_CC_PATH = ENV(CROSS_COMPILE)gcc > *_GCC44_*_SLINK_PATH = ENV(CROSS_COMPILE)ar > *_GCC44_*_DLINK_PATH = ENV(CROSS_COMPILE)ld > *_GCC44_*_ASLDLINK_PATH = ENV(CROSS_COMPILE)ld > *_GCC44_*_ASM_PATH = ENV(CROSS_COMPILE)gcc > *_GCC44_*_PP_PATH = ENV(CROSS_COMPILE)gcc > *_GCC44_*_VFRPP_PATH = ENV(CROSS_COMPILE)gcc > *_GCC44_*_ASLCC_PATH = ENV(CROSS_COMPILE)gcc > *_GCC44_*_ASLPP_PATH = ENV(CROSS_COMPILE)gcc > *_GCC44_*_RC_PATH = ENV(CROSS_COMPILE)objcopy
Why not define? DEFINE GCC44_IA32_PREFIX = ENV(TOOLS_PFX) > The reason of CROSS_COMPILE instead of TOOLS_PFX is the variable > CROSS_COMPILE is quite common when building packages with cross toolchain. I don't agree that CROSS_COMPILE is the right terminology here. For IA32/X64 is likely will not be a cross-compiler, and it is really just a prefix to the tools. Some distros will suffix their tools as well. (gcc-4.5) So, TOOLS_SFX seems like it could be useful too. > That would reduce the learning curve for new comers. > I personally do not know which version of GCC I am using. I would prefer to > drop it from the name. What about compiler flags between versions? build.sh in OvmfPkg and EmulatorPkg has seemed to work pretty well for auto-selecting the right toolchain. > I also hate to edit one line into a 5000 files; so I would definitely prefer > to move from DEF() to ENV() to define the cross-compiler. I agree that this could be useful. At one point using ENV with an undefined variable would cause a build error, but that is long since past. -Jordan > Here are some figures: > - tools_def.txt: around 5000 lines > - 7 toolchains for GCC on Linux: UNIXGCC, GCC44, GCC45, GCC46, ELFGCC, > ARMGCC, ARMLINUXGCC (around 700 lines) > - 14 toolchains for Visual Studio on Windows: VS2003, VS2003xASL, VS2005, > VS2005xASL, VS2005x86, VS2005x86xASL, VS2008, VS2008x86, VS2008xASL, > VS2008x86xASL, VS2010, VS2010x86, VS2010xASL, VS2010x86xASL (around 1860 > lines) >> -----Original Message----- >> From: Jordan Justen [mailto:jljus...@gmail.com] >> Sent: 28 May 2013 22:32 >> To: Andrew Fish >> Cc: Olivier Martin; edk2-devel@lists.sourceforge.net; edk2-buildtools- >> de...@lists.sourceforge.net >> Subject: Re: [edk2-buildtools] [PATCH] BaseTools: Add support for a >> CROSS_COMPILE ELFGCC >> >> On Tue, May 28, 2013 at 12:26 PM, Andrew Fish <af...@apple.com> wrote: >> > On May 28, 2013, at 12:10 PM, Jordan Justen <jljus...@gmail.com> >> wrote: >> >>> Anyway, I am not sure GCC for ARM architectures supports PE/COFF (I >> guess >> >>> that would 'only' required to add the PE/COFF relocation symbols). >> But if >> >>> ELFGCC is deprecated for IA32/X64 usage and ARM GCC only supports >> ELF >> >>> output, do you see any issue to re-use ELFGCC as a cross-toolchain >> ? >> >> >> >> I don't think UEFI supports ELF images for any architecture. For >> that >> >> reason, I don't think a toolchain named "*ELF*" is a good idea. >> > >> > Well the ELF bit is important as it has to do with which debugger you >> can use. It is the reason we compile to ELF and convert, so we can use >> debuggers that know about ELF images. >> > >> >> Maybe GCCCROSS is a better name? >> > >> > The problem is a gcc cross compiler could also directly produce a >> PE/COFF image, so which tool chain are you talking about? >> > >> > I vote to leave ELF in the name as it is the debug format being used. >> Well I guess we could call it DWARF to be pedantic, but Mach-O uses >> DWARF too, so ELF better maps what the debugger knows how to deal with. >> > >> >> If the debugging format is the critical element, then maybe DWARFGCC >> is the right answer. I don't agree with this though. It doesn't seem >> to follow the model of VS*/GCC*. >> >> ELFGCC seems additionally problematic given its baggage as a 'hack' >> toolchain for UnixPkg. I'd been hoping to deprecate it after >> deprecating UnixPkg. (Hmm, probably time to follow through with that.) >> >> Why this support can't be merged into the actively maintained GCC4* >> toolchains? Or, will this introduce too much confusion on these >> toolchains? >> >> I like the CROSS_COMPILE idea, but maybe instead it should be >> TOOLS_PFX? >> >> Although, doesn't CROSS_COMPILE/TOOLS_PFX gloss over the fact that >> changing the GCC version like this may mean changes are required to >> the tool arguments? >> >> -Jordan > > > > ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
