I have just sent the new patchset with 'git send-email' as you recommended.
After reviewing again the '-cr' flags, there is no reason to change the way it is today. Olivier > -----Original Message----- > From: Jordan Justen [mailto:jljus...@gmail.com] > Sent: 30 July 2013 00:14 > To: Olivier Martin > Cc: Andrew Fish; edk2-devel@lists.sourceforge.net; edk2-buildtools- > de...@lists.sourceforge.net > Subject: Re: [edk2-buildtools] [PATCH] BaseTools: Add support for a > CROSS_COMPILE ELFGCC > > Can you divide this patch up? > > I'd like to see the changes for IA32 / X64 happen first, and then a > separate patch for the ARM changes. > > Can you explain the -cr SLINK switch change? (Preferably in a good > patch commit message. :) > > -Jordan > > On Mon, Jul 29, 2013 at 11:00 AM, Olivier Martin > <olivier.mar...@arm.com> wrote: > > Here is the new version that also adds support for AArch64 in > addition to > > the 'ARM' architecture to GCC46 & GCC47 EDK2 toolchains. > > The location of the toolchains are defined by GCC46_ARM_PREFIX/ > > GCC47_ARM_PREFIX / GCC47_AARCH64_PREFIX. > > > > Let me know what you think about this version. > > > > Thanks, > > Olivier > > > >> -----Original Message----- > >> From: Jordan Justen [mailto:jljus...@gmail.com] > >> Sent: 29 May 2013 23:40 > >> To: Olivier Martin > >> Cc: Andrew Fish; 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 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 > >> > > >> > > >> > > >> > ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
