I tried this change to tools_def: -*_GCC49_X64_NASM_FLAGS = -f elf64 +GCC:*_*_X64_NASM_FLAGS = -f elf32
But, it didn't work. Does anyone know why we can't use the BUILDRULEFAMILY like this? I thought it could be helpful with: GCC:*_*_*_*_BUILDRULEORDER = nasm S -Jordan On 2014-11-12 17:47:09, Gao, Liming wrote: > Jordan and Andrew: > Now, we have BUILDRULEFAMILY, how about add BUILDRULEORDER key? It means the > priority order of the build rule for the same output with the different > postfix source files. > > *_GCC49_*_*_BUILDRULEORDER = nasm S > *_VS2013_*_*_ BUILDRULEORDER = nasm asm > *_XCODE5_*_*_ BUILDRULEORDER = S nasm > > Thanks > Liming > -----Original Message----- > From: Andrew Fish [mailto:af...@apple.com] > Sent: Saturday, November 8, 2014 12:03 PM > To: Justen, Jordan L > Cc: edk2-devel@lists.sourceforge.net; Fan, Jeff > Subject: Re: [edk2] [PATCH 000/345] Convert EDK II core packages to NASM for > IA32/X64 > > > > On Nov 7, 2014, at 7:43 PM, Jordan Justen <jordan.l.jus...@intel.com> wrote: > > > > On 2014-11-07 15:53:55, Andrew Fish wrote: > >> I was having lunch today with Mike Kinney, and Vincent Zimmer > >> (unfortunately no Tanqueray involved) and I think I’ve distilled the > >> issue down to a new feature that we need from the build system. I > >> want to be able to have an Xcode (or VC++, or Intel compiler) target > >> that uses .S (.asm) if both .S (.asm) and .nasm are present. I was > >> want to be able to have an Xcode target that uses .nasm if both the > >> .S and .nasm are present. Mike was going to go talk to the BaseTools > >> maintainers and figure out the best way to do this. > > > > Hmm. If we are considering a BaseTools change, then one thought I had > > was let a toolchain (or maybe family) select a preference list for > > certain extensions. > > > > *_GCC49_*_*_EXTENSIONS = nasm S > > *_VS2013_*_*_EXTENSIONS = nasm asm > > *_XCODE5_*_*_EXTENSIONS = S nasm > > > > I don't see rules like this in tools_def, so I'm not sure it is > > supported, but it would be nice too: > > GCC:*_*_*_*_EXTENSIONS = nasm S > > > > Basically this would only be used if 2 source files have the same base > > name. In that case, the extension listed first would be used. > > > > This would still allow XCODE to build modules that had .nasm only. > > But, for modules where a .S is available, then NASM wouldn't be > > required. > > > > That is an interesting idea! Much less impact than doing it in the INF file. > Not to mention the BUILDRULEFAMILY is more about the backend. > > I’m not sure I like EXTENSIONS as the names, but then agent the edk2 is the > poster child for it is hard to name things…. But then again maybe it is the > more future proof concept? > > I do think you are getting to the root of the issue. The BaseTools was never > designed to deal with a case where there were multiple options for what file > extension to use for a file type for a target. Adding a “universal > assembler” does introduce this class of challenge. > > I’m not saying this is the right solution, but we should ask the question > should we tie the override to the build_rule.template file sections vs. > trying to override the contents of these actions. That is just a good thing > for all of use to think about. For example are we overriding .S or > Assembly-Code-File? > > > Thanks, > > Andrew Fish > > > -Jordan > > > ------------------------------------------------------------------------------ > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
