Re: [Patch] Document: Update Build spec to remove EDK related contents

["Carsey, Jaben" <jaben.carsey@intel.com>]

Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>

> -----Original Message-----
> From: Feng, Bob C
> Sent: Monday, March 04, 2019 9:28 PM
> To: edk2-devel@lists.01.org
> Cc: Feng, Bob C <bob.c.feng@intel.com>; Gao, Liming
> <liming.gao@intel.com>; Carsey, Jaben <jaben.carsey@intel.com>
> Subject: [Patch] Document: Update Build spec to remove EDK related
> contents
> Importance: High
> 
> 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\MyMod
> Dir\MyModDir\DEBUG\AutoGen.c
> -    "$(CC)" /Fo$(OUTPUT_DIR)\AutoGen.obj $(CC_FLAGS) $(INC)
> $(WORKSPACE)\Build\MyPlatform\DEBUG_ICC\IPF\MyPlatformPkg\MyMod
> Dir\MyMod Dir\DEBUG\AutoGen.c
> +$(WORKSPACE)\Build\MyPlatform\DEBUG_ICC\X64\MyPlatformPkg\MyM
> odDir\MyModDir\DEBUG\AutoGen.c
> +    "$(CC)" /Fo$(OUTPUT_DIR)\AutoGen.obj $(CC_FLAGS) $(INC)
> $(WORKSPACE)\Build\MyPlatform\DEBUG_ICC\X64\MyPlatformPkg\MyMo
> dDir\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