From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <bob.c.feng@intel.com>
Received-SPF: Pass (sender SPF authorized) identity=mailfrom;
 client-ip=192.55.52.115; helo=mga14.intel.com;
 envelope-from=bob.c.feng@intel.com; receiver=edk2-devel@lists.01.org 
Received: from mga14.intel.com (mga14.intel.com [192.55.52.115])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by ml01.01.org (Postfix) with ESMTPS id 0C9F0211CFBFB
 for <edk2-devel@lists.01.org>; Mon,  4 Mar 2019 21:28:26 -0800 (PST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga004.jf.intel.com ([10.7.209.38])
 by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
 04 Mar 2019 21:28:26 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.58,442,1544515200"; d="scan'208";a="279797102"
Received: from shwdepsi1121.ccr.corp.intel.com ([10.239.158.47])
 by orsmga004.jf.intel.com with ESMTP; 04 Mar 2019 21:28:24 -0800
From: "Feng, Bob C" <bob.c.feng@intel.com>
To: edk2-devel@lists.01.org
Cc: Bob Feng <bob.c.feng@intel.com>, Liming Gao <liming.gao@intel.com>,
 Jaben Carsey <jaben.carsey@intel.com>
Date: Tue,  5 Mar 2019 13:28:22 +0800
Message-Id: <20190305052822.24892-1-bob.c.feng@intel.com>
X-Mailer: git-send-email 2.20.1.windows.1
MIME-Version: 1.0
Subject: [Patch] Document: Update Build spec to remove EDK related contents
X-BeenThere: edk2-devel@lists.01.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EDK II Development  <edk2-devel.lists.01.org>
List-Unsubscribe: <https://lists.01.org/mailman/options/edk2-devel>,
 <mailto:edk2-devel-request@lists.01.org?subject=unsubscribe>
List-Archive: <http://lists.01.org/pipermail/edk2-devel/>
List-Post: <mailto:edk2-devel@lists.01.org>
List-Help: <mailto:edk2-devel-request@lists.01.org?subject=help>
List-Subscribe: <https://lists.01.org/mailman/listinfo/edk2-devel>,
 <mailto:edk2-devel-request@lists.01.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Mar 2019 05:28:27 -0000
Content-Transfer-Encoding: 8bit

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1453

Remove EDK related contents from Build spec.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
---
 .../103_build_intermediate_images.md          |  3 +-
 12_build_changes_and_customizations/README.md |  4 +-
 .../42_build_process_overview.md              |  6 +-
 .../46_file_specifications.md                 | 20 +----
 6_quick_start/61_environment_variables.md     | 24 +-----
 .../82_auto-generation_process.md             | 76 +++----------------
 .../83_auto-generated_code.md                 | 43 +++--------
 .../85_auto-generated_makefiles.md            | 23 +++---
 9_build_or_make_stage/README.md               |  9 +--
 appendix_a_variables.md                       |  3 +-
 10 files changed, 43 insertions(+), 168 deletions(-)

diff --git a/10_post-build_imagegen_stage_-_flash/103_build_intermediate_images.md b/10_post-build_imagegen_stage_-_flash/103_build_intermediate_images.md
index 5f5aefc..9253cde 100644
--- a/10_post-build_imagegen_stage_-_flash/103_build_intermediate_images.md
+++ b/10_post-build_imagegen_stage_-_flash/103_build_intermediate_images.md
@@ -1,9 +1,9 @@
 <!--- @file
   10.3 Build Intermediate Images
 
-  Copyright (c) 2008-2017, Intel Corporation. All rights reserved.<BR>
+  Copyright (c) 2008-2019, Intel Corporation. All rights reserved.<BR>
 
   Redistribution and use in source (original document form) and 'compiled'
   forms (converted to PDF, epub, HTML and other formats) with or without
   modification, are permitted provided that the following conditions are met:
 
@@ -43,11 +43,10 @@ one below:
   INF_VERSION               = 0x00010017
   BASE_NAME                 = Logo
   FILE_GUID                 = 7BB28B99-61BB-11D5-9A5D-0090273FC14D
   MODULE_TYPE               = USER_DEFINED
   VERSION_STRING            = 1.0
-  EDK_RELEASE_VERSION       = 0x00020000
   EFI_SPECIFICATION_VERSION = 0x00020000
 
 [Binaries.common]
   BIN|Logo.bmp|*
 ```
diff --git a/12_build_changes_and_customizations/README.md b/12_build_changes_and_customizations/README.md
index 91e49b6..431e30f 100644
--- a/12_build_changes_and_customizations/README.md
+++ b/12_build_changes_and_customizations/README.md
@@ -1,9 +1,9 @@
 <!--- @file
   12 Build Changes and Customizations
 
-  Copyright (c) 2008-2017, Intel Corporation. All rights reserved.<BR>
+  Copyright (c) 2008-2019, Intel Corporation. All rights reserved.<BR>
 
   Redistribution and use in source (original document form) and 'compiled'
   forms (converted to PDF, epub, HTML and other formats) with or without
   modification, are permitted provided that the following conditions are met:
 
@@ -30,6 +30,6 @@
 -->
 
 # 12 Build Changes and Customizations
 
 This chapter deals with customizing a build, including options and settings for
-debugging, using custom tools as well as how to customize EDK component builds
+debugging, using custom tools.
diff --git a/4_edk_ii_build_process_overview/42_build_process_overview.md b/4_edk_ii_build_process_overview/42_build_process_overview.md
index d0725d3..17ed278 100644
--- a/4_edk_ii_build_process_overview/42_build_process_overview.md
+++ b/4_edk_ii_build_process_overview/42_build_process_overview.md
@@ -1,9 +1,9 @@
 <!--- @file
   4.2 Build Process Overview
 
-  Copyright (c) 2008-2017, Intel Corporation. All rights reserved.<BR>
+  Copyright (c) 2008-2019, Intel Corporation. All rights reserved.<BR>
 
   Redistribution and use in source (original document form) and 'compiled'
   forms (converted to PDF, epub, HTML and other formats) with or without
   modification, are permitted provided that the following conditions are met:
 
@@ -30,13 +30,11 @@
 -->
 
 ## 4.2 Build Process Overview
 
 Prior to executing a build command, specific system environment variables must
-be initialized: `WORKSPACE`, `EDK_TOOLS_PATH` are required for all builds,
-while `ECP_SOURCE`, `EFI_SOURCE` and `EDK_SOURCE` are only required to build
-EDK II platforms that contain EDK components and EDK libraries. Additionally,
+be initialized: `WORKSPACE`, `EDK_TOOLS_PATH` are required for all builds. Additionally,
 the provided EDK II tool set must be present in a directory that is in the
 system environment variable: PATH. The edksetup scripts provided in the root
 directory of the EDK II development tree will set the `WORKSPACE` and
 `EDK_TOOLS_PATH`, as well as modify the system environment variable, PATH to
 ensure that the tools can execute. Refer to "_Build Environment_" for more
diff --git a/4_edk_ii_build_process_overview/46_file_specifications.md b/4_edk_ii_build_process_overview/46_file_specifications.md
index a606488..f30f806 100644
--- a/4_edk_ii_build_process_overview/46_file_specifications.md
+++ b/4_edk_ii_build_process_overview/46_file_specifications.md
@@ -1,9 +1,9 @@
 <!--- @file
   4.6 File Specifications
 
-  Copyright (c) 2008-2017, Intel Corporation. All rights reserved.<BR>
+  Copyright (c) 2008-2019, Intel Corporation. All rights reserved.<BR>
 
   Redistribution and use in source (original document form) and 'compiled'
   forms (converted to PDF, epub, HTML and other formats) with or without
   modification, are permitted provided that the following conditions are met:
 
@@ -35,28 +35,10 @@ The EDK II Build is used to generate UEFI and PI compliant images. Additional
 reference modules may conform to Intel Framework Specifications only if there
 are no applicable UEFI or PI specification modules.
 
 The EDK II Build Tools will only generate UEFI/PI compliant images.
 
-The EDK II Compatibility Package provides libraries and header files to permit
-building some* EDK Libraries and EDK Components referenced in an EDK II
-platform (DSC) file.
-
-**********
-**Note:** \* indicates any EDK libraries or components that do not include
-assembly files and do not access flash memory can use the EDK II compatibility
-Package
-**********
-
-For some development activities, the EDK II Compatibility package can be used
-to develop and maintain original EDK platforms, components and libraries. This
-package also provides all of the tool source code used in the EDK. These tools
-are for building components and platform using the original EDK code. None of
-these tools is used for the EDK II build process. This EDK Compatibility
-package can also be used to generate files conforming to earlier releases of
-EFI and UEFI specifications.
-
 This build specification does not cover the tools or build processes for EDK
 builds nor tools provide by the EDK II Compatibility Package.
 
 The binary image files generated at the end of the $(MAKE) stage conform to the
 UEFI Images section of the _UEFI specification_. UEFI uses a subset of the
diff --git a/6_quick_start/61_environment_variables.md b/6_quick_start/61_environment_variables.md
index c90563b..9600e45 100644
--- a/6_quick_start/61_environment_variables.md
+++ b/6_quick_start/61_environment_variables.md
@@ -1,9 +1,9 @@
 <!--- @file
   6.1 Environment Variables
 
-  Copyright (c) 2008-2017, Intel Corporation. All rights reserved.<BR>
+  Copyright (c) 2008-2019, Intel Corporation. All rights reserved.<BR>
 
   Redistribution and use in source (original document form) and 'compiled'
   forms (converted to PDF, epub, HTML and other formats) with or without
   modification, are permitted provided that the following conditions are met:
 
@@ -71,17 +71,10 @@ include the trailing backslash character:
 
 `set NASM_PREFIX=C:\nasm\`
 
 ### 6.1.2 Optional Environment Variables
 
-There are two types of optional environment variables. The first type are used
-for complex development trees, while the second type of optional environment
-variables are needed build EDK components and libraries for use in an EDK II
-platform. Some EDK components and libraries can be used without modifications,
-while other EDK components and libraries will require porting to the new EDK II
-development environment.
-
 When EDK II Packages are distributed within different directory trees on a
 developer's workstation, the `PACKAGES_PATH` environment variable is used to list
 directories (prioritized from left to right) that contain EDK II Package
 directories. The operating system delimiter, such as the semi-colon character
 for Microsoft operating systems, is used to separate the directory names. If
@@ -98,20 +91,10 @@ If these Win32 binaries are located in edk2 directory tree under the
 using \*NIX operating systems must build the 'C'-based tools prior to using them
 and run the Python based tools from source, this environment variable is not
 required. The edksetup script is used to add the path to the binaries to the
 system PATH environment variable.
 
-The `EDK_SOURCE` environment variable must point to either the head of an
-existing EDK directory tree (not the EDK II directory) or the EDK II's
-`EdkCompatibilityPkg` directory.
-
-Another optional environment variable, `EFI_SOURCE`, is needed if the
-`EDK_SOURCE` environment variable is set and an EDK component and/or library is
-located outside of the `EDK_SOURCE` tree. If these values are not set, the EDK
-II build system will automatically set both values to point to the
-`EdkCompatibilityPkg` directory in the `WORKSPACE`.
-
 The final optional environment variable, `ECP_SOURCE`, is used to define the
 location of the EDK Compatibility Package content for building EDK modules. If
 these values are not set, the build system will automatically set the value to
 the `EdkCompatibilityPkg` directory in the `WORKSPACE`.
 
@@ -125,15 +108,10 @@ system environment variables, `WORKSPACE` and `EDK_TOOLS_PATH`.
 If a more complex development environment is used (multiple directories
 containing EDK II Packages), then the `WORKSPACE`, `PACKAGES_PATH` and
 `EDK_TOOLS_BIN` environment variables must be set before running the edksetup
 script.
 
-The three optional environment variables, `ECP_SOURCE`, `EDK_SOURCE` and
-`EFI_SOURCE` which are required when building EDK libraries and components in
-the context of an EDK II platform will also be set if they have not been set
-previously.
-
 The script must be executed prior to building in a new command prompt window or
 new terminal shell.
 
 Another feature of the script is that it adds the path of the build system
 tools into the OS environment variable, `PATH`.
diff --git a/8_pre-build_autogen_stage/82_auto-generation_process.md b/8_pre-build_autogen_stage/82_auto-generation_process.md
index 9b61e0d..7cdf26b 100644
--- a/8_pre-build_autogen_stage/82_auto-generation_process.md
+++ b/8_pre-build_autogen_stage/82_auto-generation_process.md
@@ -1,9 +1,9 @@
 <!--- @file
   8.2 Auto-generation Process
 
-  Copyright (c) 2008-2018, Intel Corporation. All rights reserved.<BR>
+  Copyright (c) 2008-2019, Intel Corporation. All rights reserved.<BR>
 
   Redistribution and use in source (original document form) and 'compiled'
   forms (converted to PDF, epub, HTML and other formats) with or without
   modification, are permitted provided that the following conditions are met:
 
@@ -246,13 +246,10 @@ or located under a subdirectory of the Bin directory of the EDK_TOOLS_PATH
 directory.
 
 * All EDK II content used to create PE32/PE32+ images must reside in the
   directory tree pointed to by the `WORKSPACE`.
 
-* EDK content must reside in directories pointed to by the `EFI_SOURCE`,
-  `EDK_SOURCE` and `ECP_SOURCE` system environment variables.
-
 * The build system's output directory is not required to be within the
   `WORKSPACE`.
 
 From the DSC file, the build tools collect the mapping between library classes
 and library instances (INF files), PCD data for the whole platform, the list of
@@ -380,14 +377,11 @@ be altered.
 ###### Table 9 System Environment Variable Usage
 
 | Macro Style Used in Meta-Data files | Windows Environment Variable | Linux & OS/X Environment Variable |
 |:-----------------------------------:|:----------------------------:|:---------------------------------:|
 | `$(WORKSPACE)`                      | `%WORKSPACE%`                | `$WORKSPACE`                      |
-| `$(EFI_SOURCE)`                     | `%EFI_SOURCE%`               | `$EFI_SOURCE`                     |
-| `$(EDK_SOURCE)`                     | `%EDK_SOURCE%`               | `$EDK_SOURCE`                     |
 | `$(EDK_TOOLS_PATH)`                 | `%EDK_TOOLS_PATH%`           | `$EDK_TOOLS_PATH`                 |
-| `$(ECP_SOURCE)`                     | `%ECP_SOURCE%`               | `$ECP_SOURCE`                     |
 
 **********
 **Note:** The `PACKAGES_PATH` and `EDK_TOOLS_BIN` system environment variables
 shall not be referenced in EDK II meta-data files.
 **********
@@ -413,13 +407,10 @@ conditional directives. Macros can also be defined or used in the `[Defines]`,
 `[LibraryClasses]`, `[Libraries]`, `[Components]` and all PCD sections.
 
 Macros defined by the user may be used in the !include statements in DSC and
 FDF files.
 
-`EDK_GLOBAL` type macros defined in the DSC file can be used in later sections
-of the DSC, FDF and any of the included EDK INF files.
-
 Macro values must be defined prior to using them in directive statements or for
 PCD values. The following provides the precedence (high to low) for obtaining
 macro values.
 
 * Command-line, `-D` flags (left most has higher priority)
@@ -480,15 +471,11 @@ internal build tools. These macros must not be redefined.
 | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `$(ARCH)`             | Architecture of current module                                                                                                                                                                                      |
 | `$(BASE_NAME)`        | The file name of the module binary.                                                                                                                                                                                 |
 | `$(BUILD_DIR)`        | All files for building a platform will be put in this directory                                                                                                                                                     |
 | `$(BUILD_NUMBER)`     | Used in FDF file `[Rules]` sections to identify a build number used in a UEFI Version section. This is a value that is defined in the DSC file.                                                                     |
-| `$(ECP_SOURCE)`       | The system environment variable that points to a version of the Edk Compatibility Package. This is only required if there are EDK components and libraries included in an EDK II platform build.                    |
-| `$(EDK_SOURCE)`       | The system environment variable that points to an EDK tree containing the Foundation elements of an EDK tree. This is only required if there are EDK components and libraries included in an EDK II platform build. |
 | `$(EDK_TOOLS_PATH)`   | The system environment variable that points to the path of build tools                                                                                                                                              |
-| `$(EFI_SOURCE)`       | The system environment variable that points to an EDK tree containing EDK components and libraries. This is only required if there are EDK components and libraries included in an EDK II platform build.           |
-| `$(FILE_GUID)`        | An EDK component's GUID value                                                                                                                                                                                       |
 | `$(INF_OUTPUT)`       | Used in FDF file `[Rules]` sections to identify the location of UEFI compliant binary leaf section content                                                                                                          |
 | `$(INF_VERSION)`      | Used in FDF file `[Rules]` sections to identify the version string used in a UEFI Version section.                                                                                                                  |
 | `$(MODULE_NAME)`      | Current module name                                                                                                                                                                                                 |
 | `$(MODULE_TYPE)`      | Current module type                                                                                                                                                                                                 |
 | `$(MODULE_GUID)`      | Current module GUID                                                                                                                                                                                                 |
@@ -544,28 +531,12 @@ will perform any needed tests.
 [LibraryClasses.X64.PEIM]
   # Can use $(MDE) and $(PERF)
   DEFINE MDEMEM = $(MDE)/PeiMemoryAllocationLib
   MemoryAllocationLib|$(MDEMEM)/PeiMemoryAllocationLib.inf
 
-[LibraryClasses.IPF]
-  # Cannot use $(PERF) or $(MDEMEM)
-  # Can use $(MDE) from the common section
-  PalLib|$(MDE)/UefiPalLib/UefiPalLib.inf
-  TimerLib|$(MDE)/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf
 ```
 
-#### EDK_GLOBAL
-
-The `EDK_GLOBAL` statements defined in the DSC file can be used during the
-processing of the DSC, FDF and EDK INF files. The definition of the
-`EDK_GLOBAL` name must only be done in the DSC `[Defines]` section. These
-special macros can be used in path statements, `[BuildOptions]` and `[Rule]`
-sections. These statements are used to replace the environment variables that
-were defined for the EDK build tools. They must never be used in a conditional
-directive statement in the DSC and FDF files, nor can they be used by EDK II
-INF files.
-
 #### 8.2.4.5 Conditional Directive Blocks
 
 Additional build scoping can be implemented using the DSC and FDF directive
 statements in combination with command line options for the build tool.
 Conditional directive blocks are not permitted in the EDK II DEC and INF files.
@@ -727,27 +698,14 @@ file.
 
 For logical expressions, any non-zero value must be considered `TRUE`.
 
 Invalid expressions must cause a build break with an appropriate error message.
 
-#### 8.2.4.7 EDK Overrides
-
-For EDK component INF files, an optional sub-element of `<SOURCE_OVERRIDE_PATH>`
-has been defined. If this element is specified, files listed in the directory
-are used instead of the "same-named" files in the component's directory. If an
-EDK component directory lists files, `A.c`, `B.c` and `C.h`, and the directory
-specified in this sub-element contains the file `B.c`, then the component will
-be built using files from the component directory: `A.c` and `C.h`, and the file
-`B.c` from the override directory. Any other files listed in the override
-directory will NOT be included in the build (no new or additional files are
-permitted).
-
-#### 8.2.4.8 DEPEX processing
+#### 8.2.4.7 DEPEX processing
 
 EDK II modules that have dependencies must use the `[Depex]` section to define
-the dependency expressions, however both EDK and EDK II may specify a
-dependency expression file. If the file specified, the complete dependency
+the dependency expressions. If the file specified, the complete dependency
 expression must be defined in the file. For EDK II modules, the build tools
 will create the complete dependency expression using the information in the
 `[Depex]` section along with all `[Depex]` sections from the linked in library
 instances. Depex expressions listed in an INF file's `[Depex]` section are
 written as in-fix expressions, while the output of the `GenDepex` tool
@@ -765,11 +723,11 @@ precedence for dependency expressions.
 | `AND`, `and`      | TRUE, FALSE, GUID or Encapsulation                    | These operators are used to create an expression                                                                                                                          |            |
 | `OR`, `or`        | TRUE, FALSE, GUID or Encapsulation                    | These operators are used to create an expression                                                                                                                          | Lowest     |
 | `SOR`             | TRUE, FALSE, GUID or Encapsulation                    | Only valid for DXE and SMM dependency expressions and must be the first statement followed by either a GUID, encapsulation or an expression                               |            |
 | `AFTER`, `BEFORE` | GUID                                                  | Only valid for DXE and SMM dependency expressions. These must be the only operator in the dependency expression. Only one of these is permitted per dependency expression |            |
 
-#### 8.2.4.9 PCD Access Methods
+#### 8.2.4.8 PCD Access Methods
 
 A PCD is defined as `TokenSpaceGuidCName.PcdCName`. Each PcdCName must be
 unique to the Token Space declaring the PCD. The token space is a name space
 that is unique to the GUID known as the TokenSpaceGuidCName.
 
@@ -854,11 +812,11 @@ prior to autogenerating the code.
 
 PCD values stored in VPD regions are processed prior to completing the final
 PCD parsing. Refer to Section 8.4 for additional rules for processing PCDs to
 create a platform scoped PCD Database.
 
-#### 8.2.4.10 Precedence of PCD Values
+#### 8.2.4.9 Precedence of PCD Values
 
 The values that are assigned to individual PCDs required by a build may come
 from different locations and different meta-data files. The following provides
 the precedence (high to low) to assign a value to a PCD.
 
@@ -925,11 +883,11 @@ L"Module Length"` 26 bytes, 2 bytes for null termination character).
 
 `VOID*` PCDs must be byte aligned if the value is an ASCII string, two-byte
 aligned if the value is a Unicode string or 8-byte aligned in the value is a
 byte array.
 
-#### 8.2.4.11 Section Handling
+#### 8.2.4.10 Section Handling
 
 The INF and DEC file parsing routines must process the sections so that common
 architecture sections are logically merged with the architecturally specific
 sections. The architectural sections need to be processed so that they are
 logically after the common section. It is recommended that EDK II developers
@@ -952,31 +910,19 @@ Common Section + Architectural Section + Common Section w/extra Modifier + Archi
 
 ```ini
 [BuildOptions.Common]
   MSFT:*_*_*_CC_FLAGS = /nologo
 
-[BuildOptions.Common.EDK]
-  MSFT:*_*_*_CC_FLAGS = /Od
-
 [BuildOptions.IA32]
   MSFT:*_*_IA32_CC_FLAGS = /D EFI32
 ```
 
 For IA32 architecture builds of an EDK II INF file would logically be:
 
 `MSFT:*_*_IA32_CC_FLAGS = /nologo /D EFI32`
 
-For non-IA32 architecture EDK INF files, tool parsing would logically be:
-
-`MSFT:*_*_*_CC_FLAGS = /nologo /Od`
-
-For IA32 architecture builds of an EDK INF file, tool parsing would logically
-be:
-
-`MSFT:*_*_IA32_CC_FLAGS = /nologo /D EFI32 /Od`
-
-#### 8.2.4.12 PCD INFO Generation
+#### 8.2.4.11 PCD INFO Generation
 
 The UEFI Platform Initialization specification defines a PEIM and Protocol that
 can retrieve the PCD Token number and the PCD Token Name (the PCD C Name)
 information from the PCD Database. In order to support these modules, a
 `PCD_INFO_GENERATION` entry in the DSC file's `[Defines]` section is used to
@@ -987,11 +933,11 @@ optional feature rather than always generating the content.
 
 If the `[Defines]` section has the `PCD_VAR_CHECK_GENERATION` entry set to
 TRUE, then a binary file will be created in the FV directory for Dynamic and
 DynamicEx PCD HII Variable checking.
 
-#### 8.2.4.13 Pre Build Processing
+#### 8.2.4.12 Pre Build Processing
 
 The DSC file is parsed after the tool meta-data files. If the `[Defines]`
 section of the DSC file contains a `PREBUILD = entry` statement, processing
 of the DSC file is suspended and the script specified in the `PREBUILD`
 statement is executed. The entry of `PREBUILD` support multiple arguments. And
@@ -1020,11 +966,11 @@ at the time the ENTRY was found.
 Quotes are also required if the path to the pre-build command contains space
 or special characters. Quotes may be used for arguments that have spaces or
 special characters.
 **********
 
-#### 8.2.4.14 NMAKE Command line limitation handling
+#### 8.2.4.13 NMAKE Command line limitation handling
 
 `NMAKE` is limited to command-line length of 4096 characters.  Due to the large
 number of `/I` directives specified on command line (one per include directory),
 the path length of `WORKSPACE` is multiplied by the number of `/I` directives
 and can exceed this command-line length limitation. When this issue occurs, the
@@ -1040,11 +986,11 @@ maximum command line length.  The default value is 4096.
 **Note:** The following `FLAGS` options are included in the response file:
 `PP_FLAGS`, `CC_FLAGS`, `VFRPP_FLAGS`, `APP_FLAGS`, `ASLPP_FLAGS`, `ASLCC_FLAGS`,
 and `ASM_FLAGS`.
 **********
 
-#### 8.2.4.15 Build with Binary Cache
+#### 8.2.4.14 Build with Binary Cache
 
 **build** tool provides three new options for binary cache feature.
 --hash enables hash-based caching during build process. when --hash is enabled,
 build tool will base on the module hash value to do the incremental build, without
 --hash, build tool will base on the timestamp to do the incremental build. --hash
@@ -1060,11 +1006,11 @@ hash value file into the directory specified by binary-destination at the build
 When --hash and --binary-source are specified, build tool will try to get the binary
 files from the binary source directory at the build phase. If the cached binary has
 the same hash value, it will be directly used. Otherwise, build tool will compile the
 source files and generate the binary files.
 
-#### 8.2.4.16 !error Statement
+#### 8.2.4.15 !error Statement
 
 The DSC and FDF file can use `!error` statement. The argument of this statement is an
 error message, it causes build tool to stop at the location where the statement is
 encountered and error message following the `!error` statement is output as a message.
 
diff --git a/8_pre-build_autogen_stage/83_auto-generated_code.md b/8_pre-build_autogen_stage/83_auto-generated_code.md
index 3738d92..dcb0c09 100644
--- a/8_pre-build_autogen_stage/83_auto-generated_code.md
+++ b/8_pre-build_autogen_stage/83_auto-generated_code.md
@@ -1,9 +1,9 @@
 <!--- @file
   8.3 Auto-generated code
 
-  Copyright (c) 2008-2017, Intel Corporation. All rights reserved.<BR>
+  Copyright (c) 2008-2019, Intel Corporation. All rights reserved.<BR>
 
   Redistribution and use in source (original document form) and 'compiled'
   forms (converted to PDF, epub, HTML and other formats) with or without
   modification, are permitted provided that the following conditions are met:
 
@@ -158,16 +158,13 @@ process Unicode files listed in a module's INF file. Also note that the IFR
 code is not compatible - UFI compliant IFR code is different from the IFR code
 defined by early Intel Framework documents.
 
 #### 8.3.3.1 Reference Implementation: Compatibility
 
-The EDK II Vfr compiler tools can process EDK and EDK II VFR and Unicode files
+The EDK II Vfr compiler tools can process EDK II VFR and Unicode files
 and to generate UEFI/PI compliant IFR files. EDK II Unicode files can use the
-UEFI defined Unicode extended grammar. The EDK VFR and Unicode files are a
-subset of the EDK II versions. EDK II VFR and Unicode files may not be used
-with an EDK build unless they do not include the extended grammar. Table 15
-shows the compatibility matrix.
+UEFI defined Unicode extended grammar. Table 15 shows the compatibility matrix.
 
 ###### Table 15 VFR Compatibility Matrix
 
 | Code                        | non-UEFI Compliant VFR Tools | UEFI Compliant VFR Tools |
 | --------------------------- |:----------------------------:|:------------------------:|
@@ -194,12 +191,10 @@ information into HII string pack data structure.
 
 * For EDK II modules, their Unicode files must use RFC 4646 language codes. If
   an EDK II module's Unicode file contains a three character ISO 639-2 language
   code, the build will break with an appropriate warning message.
 
-* For EDK components, their Unicode files must use the ISO 639-2 language codes.
-
 **********
 **Note:** Tools must not refactor the EDK component ISO 639-2 language codes to
 RFC 4646 language codes, as the DXE drivers are responsible for handling the
 different language code formats.
 **********
@@ -378,37 +373,21 @@ include_statement (AutoGen.h, "
   extern "C" {
   #endif
 ");
 ```
 
-#### 8.3.6.2 Global macro definitions
-
-If they are defined in INF file, un-defining them first is for backward
-compatibility with EDK module build, because these macros are not defined in
-INF file of EDK modules but passed via compiler option.
-
-```c
-include_statement (AutoGen.h, "
-  #undef EFI_SPECIFICATION_VERSION
-  #define EFI_SPECIFICATION_VERSION 0x00020000
-
-  #undef EDK_RELEASE_VERSION
-  #define EDK_RELEASE_VERSION 0x00020000
-");
-```
-
-#### 8.3.6.3 Header file inclusion.
+#### 8.3.6.2 Header file inclusion.
 
 Only one header file is included.
 
 ```c
 include_statement (AutoGen.h, "
   #include <Base.h>
 ");
 ```
 
-#### 8.3.6.4 Caller ID GUID definition.
+#### 8.3.6.3 Caller ID GUID definition.
 
 The GUID value is the same as INF file GUID. The macro, `EFI_CALLER_ID_GUID`,
 is generated only for non - library module.
 
 ```c
@@ -419,16 +398,16 @@ include_statement (AutoGen.h, "
     { 0x6987936E, 0xED34, 0x44db, { 0xAE, 0x97, 0x1F, 0xA5, 0xE4, 0xED,
       0x21, 0x16 } }
 ");
 ```
 
-#### 8.3.6.5 PCD definitions
+#### 8.3.6.4 PCD definitions
 
 There are differences in the generated code for library and non-library
 modules, which are illustrated in pseudo-code below.
 
-##### 8.3.6.5.1 Non-library Module
+##### 8.3.6.4.1 Non-library Module
 
 ```c
 include_statement(AutoGen.h, "
   #define _PCD_TOKEN_<TokenCName> <TokenNumber>
 ");
@@ -541,11 +520,11 @@ If (PCD_type == DYNAMIC_EX) {
     ");
   }
 }
 ```
 
-##### 8.3.6.5.2 Library Module
+##### 8.3.6.4.2 Library Module
 
 ```c
 nclude_statement(AutoGen.h, "
   #define _PCD_TOKEN_<TokenCName> <TokenNumber>
 ");
@@ -626,11 +605,11 @@ If (PCD_type == DYNAMIC_EX) {
     ");
   }
 }
 ```
 
-##### 8.3.6.5.3 HII string pack definitions,
+##### 8.3.6.4.3 HII string pack definitions,
 
 These are generated only if `.uni` files are found. For details, please refer
 to section 7.3.2.
 
 ```c
@@ -651,11 +630,11 @@ include_statement (AutoGen.h, "
   #define STRING_ARRAY_NAME MiscSubclassStrings
 
 ");
 ```
 
-##### 8.3.6.5.4 HII image pack definitions
+##### 8.3.6.4.4 HII image pack definitions
 
 These are generated only if `.idf` files are found.
 ```
 include_statement(AutoGen.h, "
   //
@@ -668,11 +647,11 @@ include_statement(AutoGen.h, "
 
   #define IMAGE_ARRAY_NAME  HelloWorldImages
 ");
 ```
 
-#### 8.3.6.6 AutoGen Epilogue
+#### 8.3.6.5 AutoGen Epilogue
 
 ```c
 #ifdef __cplusplus
 }
 #endif
diff --git a/8_pre-build_autogen_stage/85_auto-generated_makefiles.md b/8_pre-build_autogen_stage/85_auto-generated_makefiles.md
index fa8d5c4..161faa9 100644
--- a/8_pre-build_autogen_stage/85_auto-generated_makefiles.md
+++ b/8_pre-build_autogen_stage/85_auto-generated_makefiles.md
@@ -1,9 +1,9 @@
 <!--- @file
   8.5 Auto-generated Makefiles
 
-  Copyright (c) 2008-2017, Intel Corporation. All rights reserved.<BR>
+  Copyright (c) 2008-2019, Intel Corporation. All rights reserved.<BR>
 
   Redistribution and use in source (original document form) and 'compiled'
   forms (converted to PDF, epub, HTML and other formats) with or without
   modification, are permitted provided that the following conditions are met:
 
@@ -46,12 +46,12 @@ target is "fds", after the module builds successfully, the build tool calls the
 GenFds tool to regenerate an FD file.
 
 ### 8.5.1 Module Makefile
 
 This section describe the formats of the individual component/module Makefiles.
-Users may generate a custom makefile for their EDK component or EDK II module
-based on the information provided by this section.
+Users may generate a custom makefile for their EDK II module based on the information 
+provided by this section.
 
 The module `Makefile` is composed by two parts: macro definitions and target
 definitions.
 
 In the pseudo-code provided, the MACRO, `$(MODULE_BUILD_DIR)` is constructed
@@ -297,16 +297,13 @@ system has to build libraries that the current module needs in module's
 `Makefile`. "`mbuild`" target is used for this purpose.
 
 ```
 mbuild: $(INIT_TARGET) gen_libs $(CODA_TARGET)
 gen_libs:
-    cd $(BUILD_DIR)\IPF\MdePkg\Library\DxePcdLib\DxePcdLib && "$(MAKE)"
+    cd $(BUILD_DIR)\X64\MdePkg\Library\DxePcdLib\DxePcdLib && "$(MAKE)"
 $(MAKE_FLAGS)
-    cd $(BUILD_DIR)\IPF\MdePkg\Library\BaseLib\BaseLib && "$(MAKE)"
-$(MAKE_FLAGS)
-    cd $(BUILD_DIR)\IPF\CsiCpuUncorePkg\Library\ItcTimerLib\ItcTimerLib
-&& "$(MAKE)" $(MAKE_FLAGS)
+    cd $(BUILD_DIR)\X64\MdePkg\Library\BaseLib\BaseLib && "$(MAKE)"
     cd $(MODULE_BUILD_DIR)
 ```
 
 ##### 8.5.1.2.4 "init" target
 
@@ -342,12 +339,12 @@ $(DEBUG_DIR)\$(MODULE_NAME).efi : $(DEBUG_DIR)\$(MODULE_NAME).dll
     $(CP) $(DEBUG_DIR)\$(MODULE_NAME).efi $(OUTPUT_DIR)
     $(CP) $(DEBUG_DIR)\$(MODULE_NAME).efi $(BIN_DIR)
     -$(CP) $(DEBUG_DIR)\*.map $(OUTPUT_DIR)
 
 $(OUTPUT_DIR)\AutoGen.obj : \
-$(WORKSPACE)\Build\MyPlatform\DEBUG_ICC\IPF\MyPlatformPkg\MyModDir\MyModDir\DEBUG\AutoGen.c
-    "$(CC)" /Fo$(OUTPUT_DIR)\AutoGen.obj $(CC_FLAGS) $(INC) $(WORKSPACE)\Build\MyPlatform\DEBUG_ICC\IPF\MyPlatformPkg\MyModDir\MyMod Dir\DEBUG\AutoGen.c
+$(WORKSPACE)\Build\MyPlatform\DEBUG_ICC\X64\MyPlatformPkg\MyModDir\MyModDir\DEBUG\AutoGen.c
+    "$(CC)" /Fo$(OUTPUT_DIR)\AutoGen.obj $(CC_FLAGS) $(INC) $(WORKSPACE)\Build\MyPlatform\DEBUG_ICC\X64\MyPlatformPkg\MyModDir\MyMod Dir\DEBUG\AutoGen.c
 ```
 
 ##### 8.5.1.2.6 clean, cleanall, cleanlib
 
 Targets used to delete part or all files generated during build.
@@ -360,13 +357,11 @@ cleanall:
     if exist $(DEBUG_DIR) rmdir /s /q $(DEBUG_DIR)
     if exist $(OUTPUT_DIR) rmdir /s /q $(OUTPUT_DIR)
     del /f /q *.pdb *.idb > NUL 2>&1
 
 cleanlib:
-    cd $(BUILD_DIR)\IPF\MdePkg\Library\DxePcdLib\DxePcdLib && \
-      "$(MAKE)" $(MAKE_FLAGS) cleanall
-    cd $(BUILD_DIR)\IPF\MdePkg\Library\BaseLib\BaseLib && \
+    cd $(BUILD_DIR)\X64\MdePkg\Library\DxePcdLib\DxePcdLib && \
       "$(MAKE)" $(MAKE_FLAGS) cleanall
-    cd $(BUILD_DIR)\IPF\CsiCpuUncorePkg\Library\ItcTimerLib\ItcTimerLib && \
+    cd $(BUILD_DIR)\X64\MdePkg\Library\BaseLib\BaseLib && \
       "$(MAKE)" $(MAKE_FLAGS) cleanall
     cd $(MODULE_BUILD_DIR)
 ```
diff --git a/9_build_or_make_stage/README.md b/9_build_or_make_stage/README.md
index 1a82bda..086d5b6 100644
--- a/9_build_or_make_stage/README.md
+++ b/9_build_or_make_stage/README.md
@@ -1,9 +1,9 @@
 <!--- @file
   9 Build or $(MAKE) Stage
 
-  Copyright (c) 2008-2017, Intel Corporation. All rights reserved.<BR>
+  Copyright (c) 2008-2019, Intel Corporation. All rights reserved.<BR>
 
   Redistribution and use in source (original document form) and 'compiled'
   forms (converted to PDF, epub, HTML and other formats) with or without
   modification, are permitted provided that the following conditions are met:
 
@@ -31,14 +31,13 @@
 
 # 9 Build or $(MAKE) Stage
 
 This chapter describes the processing of the source files into EFI files.
 
-The make stage starts out by building required libraries, followed by the EDK
-components and finally, EDK II modules. The outputs of this stage are linked
-PE32+/COFF images that have been processed to replace the standard header with
-an appropriate EFI header.
+The make stage starts out by building required libraries, followed by EDK II modules. 
+The outputs of this stage are linked PE32+/COFF images that have been processed 
+to replace the standard header with an appropriate EFI header.
 
 How a file will be processed is defined in the file specified by the
 `BUILD_RULE_CONF` statement in target.txt or the default file
 `$(WORKSPACE)/Conf/build_rule.txt`. The build system will use the sections in
 this file to convert to actions and targets in the Makefile. In the previous
diff --git a/appendix_a_variables.md b/appendix_a_variables.md
index b3e4da7..4d39989 100644
--- a/appendix_a_variables.md
+++ b/appendix_a_variables.md
@@ -1,9 +1,9 @@
 <!--- @file
   Appendix A Variables
 
-  Copyright (c) 2008-2017, Intel Corporation. All rights reserved.<BR>
+  Copyright (c) 2008-2019, Intel Corporation. All rights reserved.<BR>
 
   Redistribution and use in source (original document form) and 'compiled'
   forms (converted to PDF, epub, HTML and other formats) with or without
   modification, are permitted provided that the following conditions are met:
 
@@ -59,11 +59,10 @@ optional system environment variable.
 | `BIN_DIR`         | L   | Specifies the directory where final component binaries are deposited during build. Typically `$(BUILD_DIR)\$(PROCESSOR)`                                                                                                                                                                                                                                                                                                   |
 | `BUILD_DIR`       | G   | Defines the build tip directory for the current platform. For example, this may be `$(EFI_SOURCE)\Platform\Anacortes_870`.                                                                                                                                                                                                                                                                                                 |
 | `BUILD_TYPE`      | L   | If defined, then the utility will copy the `[build.$(PROCESSOR).$(BUILD_TYPE)]` section from the DSC file to the component's makefile. If not specified, then the `[build.$(PROCESSOR).$(COMPONENT_TYPE)]` section will be used to emit command to build the component.                                                                                                                                                    |
 | `DEST_DIR`        | L   | For a component, defines the directory (typically under `BUILD_DIR`) where the component object files are to be built.                                                                                                                                                                                                                                                                                                     |
 | `DSC_FILENAME`    | G   | Name of the DSC file as specified on the command line. Can be used for dependencies in the Makefiles.                                                                                                                                                                                                                                                                                                                      |
-| `EDK_SOURCE`      | G   | Defines the root directory of the local EFI source tree, for example `C:\EFI2.0` If not defined as an environmental variable when the tool is invoked, the utility will attempt to determine a reasonable value based on the current working directory.                                                                                                                                                                    |
 | `FILE`            | L   | As the utility processes each source file in the Platform (DSC) file, this symbol gets assigned the name of the file, less the file extension.                                                                                                                                                                                                                                                                             |
 | `FV_EXT`          | L   | Common component type (BS driver, application, etc.) have predefined file name extensions assigned (.dxe, .app, etc.). If there is a deviation from the convention, or a new (unknown to the utility) component type is being built, then `FV_EXT` may need to be defined for the component so the utility knows the result file name extension. This information is necessary to generate dependencies in `makefile.out`. |
 | `INF_FILENAME`    | L   | Name of the INF file for a given component. Can be used for dependencies in the Makefiles.                                                                                                                                                                                                                                                                                                                                 |
 | `LIB_DIR`         | L   | Specifies the directory where EFI libraries are deposited after building. Typically `$(BUILD_DIR)\$(PROCESSOR)`                                                                                                                                                                                                                                                                                                            |
 | `MAKEFILE_NAME`   | L   | Name of the output makefile for the component. Default is "makefile". This value can be overridden to support building different variations of a component in the same DEST_DIR directory.                                                                                                                                                                                                                                 |
-- 
2.20.1.windows.1