On 2014-11-07 20:03:09, Andrew Fish wrote: > > 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'm not sure of a good name here. EXTORDER, EXTSEARCH and EXTPREFERENCE where some other (not great) thoughts. > 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? Yeah. I see that build_rule has some interaction. But, I'm not sure exactly what mechanism causes '.asm' files to get ignored when building with GCC toolchains. It is certainly convenient. :) Anyway, I thought that something like this would make it more explicit. (Yet, not be too burdensome to configure.) -Jordan ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
