On 2016-06-16 10:14:50, Bill Paul wrote: > Of all the gin joints in all the towns in all the world, Jordan Justen had to > walk into mine at 09:37:31 on Thursday 16 June 2016 and say: > > > On 2016-06-16 09:19:41, Bill Paul wrote: > > > Of all the gin joints in all the towns in all the world, Jordan Justen > > > had to > > > > > > walk into mine at 18:11:27 on Wednesday 15 June 2016 and say: > > > > Can you use git send-email rather than KMail to send your patches, so > > > > they will be threaded? > > > > > > You know, I spent about 10 minutes looking over my patches trying to > > > think of there was *anything* I'd forgotten to do that someone might > > > nitpick me over and for once I thought I'd gotten everything right. I > > > guess should have known better. > > > > > > No, actually, I can't use git send-email. I only have one machine that's > > > setup to send e-mail and it's not the one I used for development. > > > > Yeah. I've had a similar situation with some temp dev machines. Two > > things that I've used in the past are: > > > > 1. Push the branch to a personal git repo. Fetch it on the machine > > that can send email. Generate and send the patches. > > > > 2. Generate the patches, and copy them to a machine that can send the > > patches. Use git send-email to send the patches. > > That's fine, but are you saying I have to do one of these thing right now in > order to get these patches accepted? >
No. I wouldn't say that. I don't think we should make these changes. Rather than promoting usage of mingw based toolchains, I think we should deprecate them altogether. They are not recommended toolchains for EDK II, and I think they only cause confusion. There's really nothing preventing you from having your own personal tools_def config for a toolchain. The real question is whether the toolchain is useful for a lot of people, or something we want to officially support. I'm still not sure what is preventing you from using GCC49. Last time this came up, I don't think you answered why. David had a half-way decent reason for using a mingw based toolchain, but I personally don't think it was good enough to keep a separate toolchain in tools_def.template. If we could figure out a way to deprecate toolchains, then maybe we could also have a 'community' or 'upsupported' class of toolchains. Maybe tools_def.template gets split into tools_def.supported, tools_def.deprecated, and tools_def.community. Or, maybe we could have tools_def.MINGWGCC49, and make it very clear in the comments what level of support the toolchain has. -Jordan > > > > > > On 2016-06-15 16:36:12, Bill Paul wrote: > > > > > A while ago there was some talk of updating the UNIXGCC toolchain to > > > > > support a newer version of GCC and binutils. Unfortunately after > > > > > almost a year, nothing has happened. (I think Ard Biesheuvel said he > > > > > had plans to fix this, but apparently nothing came of this.) In fact > > > > > things have gotten slightly worse. > > > > > > > > > > I've listened to all the various opinions about keeping the UNIXGCC > > > > > toolchain option around, but I still think it's useful, and the fixes > > > > > to update it and make it work again are small, so I'm hoping there > > > > > won't be tremendous resistance them. > > > > > > > > I don't think we should 'upgrade' UNIXGCC. Instead, I think we should > > > > deprecate it. I think a better idea would be a MINGWGCC49 toolchain, > > > > but even then, I don't think it is worth-while to maintain a separate > > > > mingw gcc based toolchain. > > > > > > > > Any reason that you can't use an elf based GCC 4.9 with the GCC49 > > > > toolchain? This is the best supported toolchain for (non OS X) > > > > unix-like environments. > > > > > > > > -Jordan > > > > > > > > > This patch set updates the mingw-gcc-build.py script to use GCC 4.9.3 > > > > > and binutils 2.25, and updates the rules for UNIXGCC in tools_def > > > > > accordingly. The only real issue that the newer compiler version must > > > > > not use underscore decorations for X64 builds. > > > > > > > > > > Aside from fixing the build script and rules, the only problem I ran > > > > > into is that the -z linker option used for force 4K section > > > > > alignment only works ELF versions of GCC. With the MinGW linker > > > > > (which is targeted for PE/COFF), you need to use different flags. I > > > > > tried to adjust the rules to add an exception for the UNIXGCC case > > > > > without breaking the other cases. This should be thoroughly reviewed > > > > > to make sure I did it right. > > > > > > > > > > With these fixes I was able to build working IA32 and X64 release > > > > > images of the OVMF firmware on my FreeBSD/amd64 host. > > > > > > > > > > Bill Paul (2): > > > > > This commit updates the support for MinGW/UNIXGCC cross-build > > > > > > > > > > toolchain. > > > > > > > > > > This commit makes OvmfPkg builds work with UNIXGCC again. > > > > > > > > > > BaseTools/Conf/tools_def.template | 19 ++++++++++++------- > > > > > BaseTools/gcc/mingw-gcc-build.py | 11 +++++------ > > > > > OvmfPkg/OvmfPkgIa32.dsc | 3 ++- > > > > > OvmfPkg/OvmfPkgIa32X64.dsc | 3 ++- > > > > > OvmfPkg/OvmfPkgX64.dsc | 3 ++- > > > > > 5 files changed, 23 insertions(+), 16 deletions(-) > > -- > ============================================================================= > -Bill Paul (510) 749-2329 | Senior Member of Technical Staff, > wp...@windriver.com | Master of Unix-Fu - Wind River Systems > ============================================================================= > "I put a dollar in a change machine. Nothing changed." - George Carlin > ============================================================================= > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
