[edk2] [RFC] BaseTools: Avoid hard coding of Visual Studio path

Subject: [edk2] [RFC] BaseTools: Avoid hard coding of Visual Studio path

From: "Scott Duplichan" <scott@notabs.org>

To: <edk2-devel@lists.sourceforge.net>

Date: 2014-09-27 07:30:43

Before submitting a patch, I would like to hear comments or alternative
solutions. The problem is that file:

    BaseTools\Conf\tools_def.template

uses hard coded paths to Microsoft build tools. For example,

DEFINE VS2005x86_BIN=C:\Program Files (x86)\Microsoft Visual Studio 8\Vc\bin

Some consequences of this are:

1) This approach does not support bundled build tools. For projects
that need to be archived in a way that that allows easy building on a
different machine, possibly years in the future, possibly with different
Windows version, it is useful to bundle the command line portion of the
Visual Studio build tools along with the project for archiving. That way,
building the project is easy: decompress the archive and run a build command.
This works even after a clean OS install because the build tools are included
in the archive.

2) The current approach  does not work on all Windows machines. For example,
if Windows is installed on drive D:, then the hard coded path to drive C: is
invalid. Another example is a build command line that works on Win32 will
not work on Win64 due to the different name for the x86 "Program Files"
directory. Another example is the install location for rc.exe can vary
depending on what other Visual Studio versions are installed. The hard
coded rc.exe path may be wrong even if Visual Studio is installed on C:.

The best solution I can find uses the existing tools_def.template ENV()
function. The hard coded paths are replaced with environment variable
references that point to the needed build tool paths. This mechanism is
already used for some other tool chains. For example:
    *_XCLANG_*_CC_PATH = ENV(CLANG_BIN)clang

Applying this idea to the Windows tool chains overcomes the limitations of
the current hard coded paths.

One significant benefit is the elimination of redundant tool chain names.
With the current scheme, a Win32 user calling build.exe with 
--tagname=VS2008 must call with --tagname=VS2008x86 for Win64. In addition,
an INF BuildOptions entry must currently be duplicated:

[BuildOptions]
   MSFT:*_VS2008_*_CC_FLAGS = ...
   MSFT:*_VS2008x86_*_CC_FLAGS = ...

Combining the two tool chain names eliminates the need for this duplication.

A new batch file function is needed for setting up the build tool path
environment variables when a standard install of Visual Studio is used.
This batch function can derive the Visual Studio install directory from
the VSxxxCOMNTOOLS environment variable. The batch function can find the
proper rc.exe path by launching the command line build environment and
then checking the path to rc.exe.

Nasm already has a path environment variable and a similar one can be
added for IASL.exe.

Thanks,
Scott


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel