From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jaben.carsey@intel.com>
Received-SPF: Pass (sender SPF authorized) identity=mailfrom;
 client-ip=134.134.136.31; helo=mga06.intel.com;
 envelope-from=jaben.carsey@intel.com; receiver=edk2-devel@lists.01.org 
Received: from mga06.intel.com (mga06.intel.com [134.134.136.31])
 (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 58C0F211CFFDD
 for <edk2-devel@lists.01.org>; Tue,  5 Mar 2019 07:28:58 -0800 (PST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
 by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
 05 Mar 2019 07:28:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.58,444,1544515200"; d="scan'208";a="152230767"
Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205])
 by fmsmga001.fm.intel.com with ESMTP; 05 Mar 2019 07:28:57 -0800
Received: from fmsmsx125.amr.corp.intel.com (10.18.125.40) by
 fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS)
 id 14.3.408.0; Tue, 5 Mar 2019 07:28:57 -0800
Received: from fmsmsx103.amr.corp.intel.com ([169.254.2.115]) by
 FMSMSX125.amr.corp.intel.com ([169.254.2.121]) with mapi id 14.03.0415.000;
 Tue, 5 Mar 2019 07:28:56 -0800
From: "Carsey, Jaben" <jaben.carsey@intel.com>
To: "Feng, Bob C" <bob.c.feng@intel.com>, "edk2-devel@lists.01.org"
 <edk2-devel@lists.01.org>
CC: "Gao, Liming" <liming.gao@intel.com>
Thread-Topic: [Patch] Document: Update Build spec to remove EDK related
 contents
Thread-Index: AQHU0xRDSqDQAag/x0Oq1Tr5gjXQk6X9Kh5A
Date: Tue, 5 Mar 2019 15:28:55 +0000
Message-ID: <CB6E33457884FA40993F35157061515CBCB941BB@FMSMSX103.amr.corp.intel.com>
References: <20190305052822.24892-1-bob.c.feng@intel.com>
In-Reply-To: <20190305052822.24892-1-bob.c.feng@intel.com>
Accept-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZTJkMzNiNzQtNjdjMC00ZTdkLTljMjEtMjNiZWFiNGU1NzA1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiQ28rTE9TTDI4cTZsWVpCSUY2XC8wRHpwXC9tdXdHeTg5Rml0XC94ZUVwZ3hZQ1hGSUdROG95eVRqOWZlT2VvanQwaiJ9
x-ctpclassification: CTP_NT
dlp-product: dlpe-windows
dlp-version: 11.0.400.15
dlp-reaction: no-action
x-originating-ip: [10.1.200.107]
MIME-Version: 1.0
Subject: Re: [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 15:28:58 -0000
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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
>=20
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3D1453
>=20
> Remove EDK related contents from Build spec.
>=20
> 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(-)
>=20
> 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
>=20
> -  Copyright (c) 2008-2017, Intel Corporation. All rights reserved.<BR>
> +  Copyright (c) 2008-2019, Intel Corporation. All rights reserved.<BR>
>=20
>    Redistribution and use in source (original document form) and 'compile=
d'
>    forms (converted to PDF, epub, HTML and other formats) with or without
>    modification, are permitted provided that the following conditions are=
 met:
>=20
> @@ -43,11 +43,10 @@ one below:
>    INF_VERSION               =3D 0x00010017
>    BASE_NAME                 =3D Logo
>    FILE_GUID                 =3D 7BB28B99-61BB-11D5-9A5D-0090273FC14D
>    MODULE_TYPE               =3D USER_DEFINED
>    VERSION_STRING            =3D 1.0
> -  EDK_RELEASE_VERSION       =3D 0x00020000
>    EFI_SPECIFICATION_VERSION =3D 0x00020000
>=20
>  [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
>=20
> -  Copyright (c) 2008-2017, Intel Corporation. All rights reserved.<BR>
> +  Copyright (c) 2008-2019, Intel Corporation. All rights reserved.<BR>
>=20
>    Redistribution and use in source (original document form) and 'compile=
d'
>    forms (converted to PDF, epub, HTML and other formats) with or without
>    modification, are permitted provided that the following conditions are=
 met:
>=20
> @@ -30,6 +30,6 @@
>  -->
>=20
>  # 12 Build Changes and Customizations
>=20
>  This chapter deals with customizing a build, including options and setti=
ngs 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
>=20
> -  Copyright (c) 2008-2017, Intel Corporation. All rights reserved.<BR>
> +  Copyright (c) 2008-2019, Intel Corporation. All rights reserved.<BR>
>=20
>    Redistribution and use in source (original document form) and 'compile=
d'
>    forms (converted to PDF, epub, HTML and other formats) with or without
>    modification, are permitted provided that the following conditions are=
 met:
>=20
> @@ -30,13 +30,11 @@
>  -->
>=20
>  ## 4.2 Build Process Overview
>=20
>  Prior to executing a build command, specific system environment variable=
s
> must
> -be initialized: `WORKSPACE`, `EDK_TOOLS_PATH` are required for all build=
s,
> -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 build=
s.
> Additionally,
>  the provided EDK II tool set must be present in a directory that is in t=
he
>  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 mo=
re
> 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
>=20
> -  Copyright (c) 2008-2017, Intel Corporation. All rights reserved.<BR>
> +  Copyright (c) 2008-2019, Intel Corporation. All rights reserved.<BR>
>=20
>    Redistribution and use in source (original document form) and 'compile=
d'
>    forms (converted to PDF, epub, HTML and other formats) with or without
>    modification, are permitted provided that the following conditions are=
 met:
>=20
> @@ -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.
>=20
>  The EDK II Build Tools will only generate UEFI/PI compliant images.
>=20
> -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 inclu=
de
> -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. No=
ne
> 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 release=
s 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.
>=20
>  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 t=
he
> 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
>=20
> -  Copyright (c) 2008-2017, Intel Corporation. All rights reserved.<BR>
> +  Copyright (c) 2008-2019, Intel Corporation. All rights reserved.<BR>
>=20
>    Redistribution and use in source (original document form) and 'compile=
d'
>    forms (converted to PDF, epub, HTML and other formats) with or without
>    modification, are permitted provided that the following conditions are=
 met:
>=20
> @@ -71,17 +71,10 @@ include the trailing backslash character:
>=20
>  `set NASM_PREFIX=3DC:\nasm\`
>=20
>  ### 6.1.2 Optional Environment Variables
>=20
> -There are two types of optional environment variables. The first type ar=
e
> used
> -for complex development trees, while the second type of optional
> environment
> -variables are needed build EDK components and libraries for use in an ED=
K 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 char=
acter
>  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 us=
ing
> 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.
>=20
> -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, t=
he
> 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 modul=
es.
> If
>  these values are not set, the build system will automatically set the va=
lue to
>  the `EdkCompatibilityPkg` directory in the `WORKSPACE`.
>=20
> @@ -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.
>=20
> -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.
>=20
>  Another feature of the script is that it adds the path of the build syst=
em
>  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
>=20
> -  Copyright (c) 2008-2018, Intel Corporation. All rights reserved.<BR>
> +  Copyright (c) 2008-2019, Intel Corporation. All rights reserved.<BR>
>=20
>    Redistribution and use in source (original document form) and 'compile=
d'
>    forms (converted to PDF, epub, HTML and other formats) with or without
>    modification, are permitted provided that the following conditions are=
 met:
>=20
> @@ -246,13 +246,10 @@ or located under a subdirectory of the Bin director=
y
> of the EDK_TOOLS_PATH
>  directory.
>=20
>  * All EDK II content used to create PE32/PE32+ images must reside in the
>    directory tree pointed to by the `WORKSPACE`.
>=20
> -* 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`.
>=20
>  From the DSC file, the build tools collect the mapping between library c=
lasses
>  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
>=20
>  | 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`
> |
>=20
>  **********
>  **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.
>=20
>  Macros defined by the user may be used in the !include statements in DSC
> and
>  FDF files.
>=20
> -`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.
>=20
>  * 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 identif=
y a
> build number used in a UEFI Version section. This is a value that is defi=
ned 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 i=
f
> there are EDK components and libraries included in an EDK II platform bui=
ld.
> |
> -| `$(FILE_GUID)`        | An EDK component's GUID value
> |
>  | `$(INF_OUTPUT)`       | Used in FDF file `[Rules]` sections to identif=
y the
> location of UEFI compliant binary leaf section content
> |
>  | `$(INF_VERSION)`      | Used in FDF file `[Rules]` sections to identif=
y 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 =3D $(MDE)/PeiMemoryAllocationLib
>    MemoryAllocationLib|$(MDEMEM)/PeiMemoryAllocationLib.inf
>=20
> -[LibraryClasses.IPF]
> -  # Cannot use $(PERF) or $(MDEMEM)
> -  # Can use $(MDE) from the common section
> -  PalLib|$(MDE)/UefiPalLib/UefiPalLib.inf
> -
> TimerLib|$(MDE)/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf
>  ```
>=20
> -#### 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 `[Ru=
le]`
> -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 ED=
K II
> -INF files.
> -
>  #### 8.2.4.5 Conditional Directive Blocks
>=20
>  Additional build scoping can be implemented using the DSC and FDF direct=
ive
>  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.
>=20
>  For logical expressions, any non-zero value must be considered `TRUE`.
>=20
>  Invalid expressions must cause a build break with an appropriate error
> message.
>=20
> -#### 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 dire=
ctory
> -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 dir=
ectory
> -specified in this sub-element contains the file `B.c`, then the componen=
t 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 overrid=
e
> -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
>=20
>  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 dependen=
cy
> +the dependency expressions. If the file specified, the complete
> dependency
>  expression must be defined in the file. For EDK II modules, the build to=
ols
>  will create the complete dependency expression using the information in
> the
>  `[Depex]` section along with all `[Depex]` sections from the linked in l=
ibrary
>  instances. Depex expressions listed in an INF file's `[Depex]` section a=
re
>  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 |            |
>=20
> -#### 8.2.4.9 PCD Access Methods
> +#### 8.2.4.8 PCD Access Methods
>=20
>  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.
>=20
> @@ -854,11 +812,11 @@ prior to autogenerating the code.
>=20
>  PCD values stored in VPD regions are processed prior to completing the f=
inal
>  PCD parsing. Refer to Section 8.4 for additional rules for processing PC=
Ds to
>  create a platform scoped PCD Database.
>=20
> -#### 8.2.4.10 Precedence of PCD Values
> +#### 8.2.4.9 Precedence of PCD Values
>=20
>  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.
>=20
> @@ -925,11 +883,11 @@ L"Module Length"` 26 bytes, 2 bytes for null
> termination character).
>=20
>  `VOID*` PCDs must be byte aligned if the value is an ASCII string, two-b=
yte
>  aligned if the value is a Unicode string or 8-byte aligned in the value =
is a
>  byte array.
>=20
> -#### 8.2.4.11 Section Handling
> +#### 8.2.4.10 Section Handling
>=20
>  The INF and DEC file parsing routines must process the sections so that
> common
>  architecture sections are logically merged with the architecturally spec=
ific
>  sections. The architectural sections need to be processed so that they a=
re
>  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
>=20
>  ```ini
>  [BuildOptions.Common]
>    MSFT:*_*_*_CC_FLAGS =3D /nologo
>=20
> -[BuildOptions.Common.EDK]
> -  MSFT:*_*_*_CC_FLAGS =3D /Od
> -
>  [BuildOptions.IA32]
>    MSFT:*_*_IA32_CC_FLAGS =3D /D EFI32
>  ```
>=20
>  For IA32 architecture builds of an EDK II INF file would logically be:
>=20
>  `MSFT:*_*_IA32_CC_FLAGS =3D /nologo /D EFI32`
>=20
> -For non-IA32 architecture EDK INF files, tool parsing would logically be=
:
> -
> -`MSFT:*_*_*_CC_FLAGS =3D /nologo /Od`
> -
> -For IA32 architecture builds of an EDK INF file, tool parsing would logi=
cally
> -be:
> -
> -`MSFT:*_*_IA32_CC_FLAGS =3D /nologo /D EFI32 /Od`
> -
> -#### 8.2.4.12 PCD INFO Generation
> +#### 8.2.4.11 PCD INFO Generation
>=20
>  The UEFI Platform Initialization specification defines a PEIM and Protoc=
ol 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 use=
d
> to
> @@ -987,11 +933,11 @@ optional feature rather than always generating the
> content.
>=20
>  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.
>=20
> -#### 8.2.4.13 Pre Build Processing
> +#### 8.2.4.12 Pre Build Processing
>=20
>  The DSC file is parsed after the tool meta-data files. If the `[Defines]=
`
>  section of the DSC file contains a `PREBUILD =3D entry` statement, proce=
ssing
>  of the DSC file is suspended and the script specified in the `PREBUILD`
>  statement is executed. The entry of `PREBUILD` support multiple argument=
s.
> 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.
>  **********
>=20
> -#### 8.2.4.14 NMAKE Command line limitation handling
> +#### 8.2.4.13 NMAKE Command line limitation handling
>=20
>  `NMAKE` is limited to command-line length of 4096 characters.  Due to th=
e
> 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 occu=
rs,
> the
> @@ -1040,11 +986,11 @@ maximum command line length.  The default value
> is 4096.
>  **Note:** The following `FLAGS` options are included in the response fil=
e:
>  `PP_FLAGS`, `CC_FLAGS`, `VFRPP_FLAGS`, `APP_FLAGS`, `ASLPP_FLAGS`,
> `ASLCC_FLAGS`,
>  and `ASM_FLAGS`.
>  **********
>=20
> -#### 8.2.4.15 Build with Binary Cache
> +#### 8.2.4.14 Build with Binary Cache
>=20
>  **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 buil=
d,
> without
>  --hash, build tool will base on the timestamp to do the incremental buil=
d. --
> 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 ge=
t 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 wil=
l
> compile the
>  source files and generate the binary files.
>=20
> -#### 8.2.4.16 !error Statement
> +#### 8.2.4.15 !error Statement
>=20
>  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.
>=20
> 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
>=20
> -  Copyright (c) 2008-2017, Intel Corporation. All rights reserved.<BR>
> +  Copyright (c) 2008-2019, Intel Corporation. All rights reserved.<BR>
>=20
>    Redistribution and use in source (original document form) and 'compile=
d'
>    forms (converted to PDF, epub, HTML and other formats) with or without
>    modification, are permitted provided that the following conditions are=
 met:
>=20
> @@ -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 IF=
R
> code
>  defined by early Intel Framework documents.
>=20
>  #### 8.3.3.1 Reference Implementation: Compatibility
>=20
> -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 us=
e 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 u=
sed
> -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.
>=20
>  ###### Table 15 VFR Compatibility Matrix
>=20
>  | Code                        | non-UEFI Compliant VFR Tools | UEFI Comp=
liant VFR
> Tools |
>  | --------------------------- |:----------------------------:|:---------=
---------------:|
> @@ -194,12 +191,10 @@ information into HII string pack data structure.
>=20
>  * For EDK II modules, their Unicode files must use RFC 4646 language cod=
es.
> 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.
>=20
> -* For EDK components, their Unicode files must use the ISO 639-2 languag=
e
> 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
>  ");
>  ```
>=20
> -#### 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 define=
d
> 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.
>=20
>  Only one header file is included.
>=20
>  ```c
>  include_statement (AutoGen.h, "
>    #include <Base.h>
>  ");
>  ```
>=20
> -#### 8.3.6.4 Caller ID GUID definition.
> +#### 8.3.6.3 Caller ID GUID definition.
>=20
>  The GUID value is the same as INF file GUID. The macro,
> `EFI_CALLER_ID_GUID`,
>  is generated only for non - library module.
>=20
>  ```c
> @@ -419,16 +398,16 @@ include_statement (AutoGen.h, "
>      { 0x6987936E, 0xED34, 0x44db, { 0xAE, 0x97, 0x1F, 0xA5, 0xE4, 0xED,
>        0x21, 0x16 } }
>  ");
>  ```
>=20
> -#### 8.3.6.5 PCD definitions
> +#### 8.3.6.4 PCD definitions
>=20
>  There are differences in the generated code for library and non-library
>  modules, which are illustrated in pseudo-code below.
>=20
> -##### 8.3.6.5.1 Non-library Module
> +##### 8.3.6.4.1 Non-library Module
>=20
>  ```c
>  include_statement(AutoGen.h, "
>    #define _PCD_TOKEN_<TokenCName> <TokenNumber>
>  ");
> @@ -541,11 +520,11 @@ If (PCD_type =3D=3D DYNAMIC_EX) {
>      ");
>    }
>  }
>  ```
>=20
> -##### 8.3.6.5.2 Library Module
> +##### 8.3.6.4.2 Library Module
>=20
>  ```c
>  nclude_statement(AutoGen.h, "
>    #define _PCD_TOKEN_<TokenCName> <TokenNumber>
>  ");
> @@ -626,11 +605,11 @@ If (PCD_type =3D=3D DYNAMIC_EX) {
>      ");
>    }
>  }
>  ```
>=20
> -##### 8.3.6.5.3 HII string pack definitions,
> +##### 8.3.6.4.3 HII string pack definitions,
>=20
>  These are generated only if `.uni` files are found. For details, please =
refer
>  to section 7.3.2.
>=20
>  ```c
> @@ -651,11 +630,11 @@ include_statement (AutoGen.h, "
>    #define STRING_ARRAY_NAME MiscSubclassStrings
>=20
>  ");
>  ```
>=20
> -##### 8.3.6.5.4 HII image pack definitions
> +##### 8.3.6.4.4 HII image pack definitions
>=20
>  These are generated only if `.idf` files are found.
>  ```
>  include_statement(AutoGen.h, "
>    //
> @@ -668,11 +647,11 @@ include_statement(AutoGen.h, "
>=20
>    #define IMAGE_ARRAY_NAME  HelloWorldImages
>  ");
>  ```
>=20
> -#### 8.3.6.6 AutoGen Epilogue
> +#### 8.3.6.5 AutoGen Epilogue
>=20
>  ```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
>=20
> -  Copyright (c) 2008-2017, Intel Corporation. All rights reserved.<BR>
> +  Copyright (c) 2008-2019, Intel Corporation. All rights reserved.<BR>
>=20
>    Redistribution and use in source (original document form) and 'compile=
d'
>    forms (converted to PDF, epub, HTML and other formats) with or without
>    modification, are permitted provided that the following conditions are=
 met:
>=20
> @@ -46,12 +46,12 @@ target is "fds", after the module builds successfully=
,
> the build tool calls the
>  GenFds tool to regenerate an FD file.
>=20
>  ### 8.5.1 Module Makefile
>=20
>  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 th=
e
> information
> +provided by this section.
>=20
>  The module `Makefile` is composed by two parts: macro definitions and
> target
>  definitions.
>=20
>  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.
>=20
>  ```
>  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)
>  ```
>=20
>  ##### 8.5.1.2.4 "init" target
>=20
> @@ -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)
>=20
>  $(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
>  ```
>=20
>  ##### 8.5.1.2.6 clean, cleanall, cleanlib
>=20
>  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
>=20
>  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
>=20
> -  Copyright (c) 2008-2017, Intel Corporation. All rights reserved.<BR>
> +  Copyright (c) 2008-2019, Intel Corporation. All rights reserved.<BR>
>=20
>    Redistribution and use in source (original document form) and 'compile=
d'
>    forms (converted to PDF, epub, HTML and other formats) with or without
>    modification, are permitted provided that the following conditions are=
 met:
>=20
> @@ -31,14 +31,13 @@
>=20
>  # 9 Build or $(MAKE) Stage
>=20
>  This chapter describes the processing of the source files into EFI files=
.
>=20
> -The make stage starts out by building required libraries, followed by th=
e EDK
> -components and finally, EDK II modules. The outputs of this stage are li=
nked
> -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 ED=
K 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.
>=20
>  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 sectio=
ns
> in
>  this file to convert to actions and targets in the Makefile. In the prev=
ious
> 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
>=20
> -  Copyright (c) 2008-2017, Intel Corporation. All rights reserved.<BR>
> +  Copyright (c) 2008-2019, Intel Corporation. All rights reserved.<BR>
>=20
>    Redistribution and use in source (original document form) and 'compile=
d'
>    forms (converted to PDF, epub, HTML and other formats) with or without
>    modification, are permitted provided that the following conditions are=
 met:
>=20
> @@ -59,11 +59,10 @@ optional system environment variable.
>  | `BIN_DIR`         | L   | Specifies the directory where final componen=
t binaries
> are deposited during build. Typically `$(BUILD_DIR)\$(PROCESSOR)`
> |
>  | `BUILD_DIR`       | G   | Defines the build tip directory for the curr=
ent
> 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 (typi=
cally
> 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 reasona=
ble
> 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, applicatio=
n, etc.)
> have predefined file name extensions assigned (.dxe, .app, etc.). If ther=
e is a
> deviation from the convention, or a new (unknown to the utility) componen=
t
> type is being built, then `FV_EXT` may need to be defined for the compone=
nt
> 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 directo=
ry.
> |
> --
> 2.20.1.windows.1