> 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
