* [Patch V2 1/1] Document: Update Build spec to remove EDK related contents
2019-03-06 7:49 [Patch V2 0/1] Document: Update Build spec to remove EDK related Feng, Bob C
@ 2019-03-06 7:49 ` Feng, Bob C
2019-03-06 8:29 ` [Patch V2 0/1] Document: Update Build spec to remove EDK related Gao, Liming
1 sibling, 0 replies; 4+ messages in thread
From: Feng, Bob C @ 2019-03-06 7:49 UTC (permalink / raw)
To: edk2-devel; +Cc: Bob Feng, Liming Gao, Jaben Carsey
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>
---
10_post-build_imagegen_stage_-_flash/103_build_intermediate_images.md | 3 +--
12_build_changes_and_customizations/README.md | 4 ++--
4_edk_ii_build_process_overview/42_build_process_overview.md | 6 ++----
4_edk_ii_build_process_overview/46_file_specifications.md | 20 +-------------------
6_quick_start/61_environment_variables.md | 24 +-----------------------
8_pre-build_autogen_stage/82_auto-generation_process.md | 76 +++++++++++-----------------------------------------------------------------
8_pre-build_autogen_stage/83_auto-generated_code.md | 43 +++++++++++--------------------------------
8_pre-build_autogen_stage/85_auto-generated_makefiles.md | 23 +++++++++--------------
9_build_or_make_stage/README.md | 9 ++++-----
README.md | 1 +
appendix_a_variables.md | 3 +--
11 files changed, 44 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/README.md b/README.md
index 637a4a4..b51a382 100644
--- a/README.md
+++ b/README.md
@@ -227,5 +227,6 @@ Copyright (c) 2008-2017, Intel Corporation. All rights reserved.
| | Update description for build handles PCDs for SKU support | |
| | Add statement about module scoped `<Pcd*>` section override scope | |
| | Add !error statement section | |
| | [#1110](https://bugzilla.tianocore.org/show_bug.cgi?id=1110) Extend exclamation statement's keyword to case-insensitive | |
| | [#598](https://bugzilla.tianocore.org/show_bug.cgi?id=598) update supported operators in 8.2.4.6 Expressions | |
+| 1.29 | [#1453](https://bugzilla.tianocore.org/show_bug.cgi?id=1453) Update Build spec to remove EDK related contents | Mar 2019 |
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
^ permalink raw reply related [flat|nested] 4+ messages in thread