[PATCH 0/1] Update for the 2017-10-18 VS2017 proposal

[Pete Batard <pete@akeo.ie>]

The following is a set of changes that I'd like to see applied to Liming's
2017-10-18 VS2017 support proposal for IA32 and X64.
(See https://lists.01.org/pipermail/edk2-devel/2017-October/016175.html)

Since I am planning to submit a v2 of my VS2017 ARM/AARCH64 proposal, that
relies on these alterations, I am sending this preliminary patch for review.

The 3 main changes that are being introduced from the existing proposal are:
1. The use of %WindowsSdkVerBinPath% if defined, to locate the most recent
   version of the Windows 10 SDK. The fact that vcvars32.bat should have been
   called should usually ensure that this variable has been set, which in turn
   should ensure that we can access the required ARM64 tools and libraries. Of
   course, if the variable is not defined, the fallback to the hardcoded SDK
   top directory should still work fine for IA32 and X64.
2. Follow the way Microsoft structured the Visual Studio 2017 toolchains by
   introducing a specific VS2017_BIN_HOST, for host-specific elements, that is
   separate from the various VS2017_BIN_<ARCH> targets. I believe this will
   make maintenance easier in the long run, as it makes the breakdown of what
   relates to the host and what relates to the target a lot more explicit.
   Note that, for clarity's sake, and unlike the convention that was used
   previously, I chose to add an underscore between BIN and <ARCH>. This is
   because, once we start dealing with things like VS2017_BIN_ARM and
   VS2017_BIN_AARCH64, we'll probably be happier with a separator for <ARCH>.
3. Factorize the elements that are HOST related, since they don't need to be
   duplicated.

I'm hoping that these alterations can be agreed on. If that is the case, and
considering that these changes need to be applied on top of the current VS2017
proposal, I can submit a v2 of Liming's patches, that includes these changes,
for review and integration.

I should also point out that, outside of these modification, the current
proposal looks good to me especially as I have tested the generation of the
IA32 and X64 OVMF using VS2017 (from a regular command prompt rather than a
VS2017 one), as well as a handful of IA32 and X64 applications and found no
issues. For the sake of validating my proposed changes, I tested both the
x86 and x64 VS2017 HOSTs.

Regards,

/Pete

Pete Batard (1):
  BaseTools: Use VS2017 SDK path if defined and reorganize variables

 BaseTools/Conf/tools_def.template | 66 ++++++++++++++++++---------------------
 BaseTools/set_vsprefix_envs.bat   | 15 ++++-----
 2 files changed, 39 insertions(+), 42 deletions(-)

-- 
2.9.3.windows.2