Tianocore/edk2.git/BaseTools/Source/Python/Workspace, branch master

BaseTools: Make DSC arch macro expansion owner-aware

2026-09-01T14:42:26+00:00

PR #12628 expanded architecture macros for every DSC record so component-private records match their component. A positive raw owner can also represent include provenance, so broad expansion changes records outside component scope. Expand architecture macros only for Component records and records whose owner maps to a final Component. Reset the owner mapping whenever the post-processed table is rebuilt to prevent stale ownership across DoPostProcess calls. Add regression coverage for component-private LibraryClasses and PCDs, nested and private includes, multiple architectures, unresolved macros, repeated sections, and repeated post-processing. Signed-off-by: Bob Chen (UST Global Singapore Pte Limited)

BaseTools/Build: Output warning message for library class mismatch

2026-08-06T04:55:34+00:00

Performs a check that will verify that the library instance implements the library specified in the dsc by ensuring a LIBRARY_CLASS definition exists in the INF [Defines] section and the value matches the library it says it is implementing. As an example, from a platform dsc file: BaseBmpSupportLib|MdeModulePkg/Library/BaseBmpSupportLib/BaseBmpSupportLib.inf BaseBmpSupportLib is supposed to be of library class BmpSupportLib, but the dsc defines it incorrectly, the warning message will be displayed during build. Signed-off-by: Aaron Pop Co-authored-by: Poncho Figueroa

BaseTools: Fix Clang -Wtautological-overlap-compare in PcdValueInit.c

2026-08-01T16:17:54+00:00

For each structured-PCD field copied via memcpy, DscBuildData.py emits the clamp expression, '(FieldSize > 0 && FieldSize < ValueSize) ? FieldSize : ValueSize'. When ValueSize == 1 and FieldSize is unsigned, it reduces to (FieldSize > 0 && FieldSize < 1) - always-false comparison. Clang flags it under -Wtautological-overlap-compare, and because PcdValueInit builds with -Werror, autogen fails and the build aborts with 'PcdValueInit.c: error: overlapping comparisons always evaluate to false [-Werror,-Wtautological-overlap-compare]'. This is specific to Clang host. To fix it, this update changes '<' to '<=' at all five generator sites in DscBuildData.py (GenerateDefaultValueAssignFunction, GenerateInitValueFunction, GenerateCommandLineValue, GenerateModuleScopeValue, GenerateFdfValue). Behavior is unchanged: both branches copy the same byte count when FieldSize == ValueSize. GCC and MSVC builds are unaffected. Signed-off-by: Phil Noh

BaseTools/Build: Fix arch macro expansion scope in DSC parser

2026-06-23T02:21:25+00:00

Signed-off-by: Kirk Chou

Revert "BaseTools: Add support for out-of-tree builds"

2026-02-11T22:53:29+00:00

This reverts commit 3fe1d56cc98e011bbde8348f13dfa5e38c95f49e. PR https://github.com/tianocore/edk2/pull/11757 introduced a "Breaking Change" feature for out of tree builds of tools. This breaking change is blocking testing of edk2-stable202602 due to side effects on building FitGen tool in edk2-platforms. Revert this feature for the edk2-stable202602 release and work on this feature after the release. Signed-off-by: Michael D Kinney

BaseTools: Add support for out-of-tree builds

2026-02-02T08:56:31+00:00

Main EDK2 build supports out-of-tree builds but BaseTools make process still creates tools and object files in-tree. In order to make out-of-tree build support complete move the generated tools and interim obj files to $WORKSPACE location as well. This patch also changes the location of BaseTools for in-tree builds (default behavior when WORKSPACE is not provided before calling edksetup) to $WORKSPACE/BaseTools/Build/... It may potentially break external workflows that invoke tools from the default location outside of the build tool. Signed-off-by: Oleksandr Tymoshenko

BaseTools: Prevent Subsection PCDs from polluting global expressions

2026-01-30T09:55:39+00:00

The PCD value defined in module subsections can be added to global PCD database. Therefore the unsolved expressions, even belongs to the global scope, can incorrectly refer to the value from module subsection. This only happens when the referred PCD has no value assignment in the platform dsc file. Which also should raise an error. Signed-off-by: Paddy Deng

BaseTools: fix various typos

2025-11-21T21:49:59+00:00

This commit is the first in a series of multiple commits to fix various typos in the code, originating mostly from copy&paste over the years. Most of them only affect documentation and not code. Signed-off-by: Philipp Schuster

BaseTools: Remove DXE_SAL_DRIVER

2025-10-30T10:00:32+00:00

The DXE_SAL_DRIVER module type was introduced to support Itanium (IPF) platforms. Since support for Itanium processors has been dropped, the instances of DXE_SAL_DRIVER have been removed. Ref: [3cb0a311cb7e747d7be5c5076d0fff76ad256d2b] Cc: Sachin Ganesh Signed-off-by: Sathya Ravichandran

BaseTools: DSC: fix processing !include in multiarch subsections

2025-08-25T11:54:17+00:00

Commit f0a2015373 ("UefiPayloadPkg: Add AARCH64 support") changed `[Components.X64]` to `[Components.X64, Components.AARCH64]` which resulted in the following code within that section to not work as expected (the code wasn't there, just providing a real world example that uncovered the issue): [Components.X64, Components.AARCH64] FmpDevicePkg/FmpDxe/FmpDxe.inf { ... !include .../...PcdFmpDevicePkcs7CertBufferXdr.inc ... } At the same time `[Components.X64]` or even `[Components.AARCH64, Components.X64]` (notice the swapped order) worked fine for X64 target. The cause of the issue turned out to be skipping includes inside `_PostProcess()` method of `DscParser` class. This method processes list of items stored in a database filled on the first pass through a DSC file in `Start()` method. One of the fields stored in each row of a table is link to a parent object (owner). A section like `[Components.X64, Components.AARCH64]` creates two objects and all of its subelements are duplicated for both X64 and AARCH64. This was not happening for !include statement in the example above. Because `_PostProcess()` contracted a sequence of !include objects disregarding their owner, it did not create instance for each of the requested targets. Codewise, `self._ContentIndex` was incremented more than once, while `__ProcessDirective()` method (invoked indirectly as `Processer[self._ItemType]()`) queried owner of the current directive as: if self._InSubsection: Owner = self._Content[self._ContentIndex - 1][8] else: # not taken in this case This is why order of targets made a difference, only the last was fully initialized in this case. An alternative fix is completely dropping merging of !include directives, but hard to say whether it still has some utility (the code is complex, hard to follow and barely documented). Safer to keep it, in the worst case it doesn't do anything now. Signed-off-by: Sergii Dmytruk