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

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

BaseTools: Fix the spelling or typo

2025-07-04T01:41:47+00:00

Signed-off-by: Abdul Lateef Attar

BaseTools: WorkSpace: Remove unnecessary code

2025-07-01T01:51:38+00:00

Running the vulture tool on the WorkSpace folder gave the following report. Remove the unnecessary code. - Workspace/BuildClassObject.py:148: unused method 'IsSimpleTypeArray' (60% confidence) - Workspace/BuildClassObject.py:337: unused method 'SetPcdMode' (60% confidence) - Workspace/BuildClassObject.py:612: unused attribute 'DscSpecification' (60% confidence) - Workspace/DscBuildData.py:451: unused property 'DscSpecification' (60% confidence) - Workspace/DscBuildData.py:1253: unused method 'GetBuildOptionsByPkg' (60% confidence) - Workspace/DscBuildData.py:2064: unused method 'GetStarNum' (60% confidence) - Workspace/DscBuildData.py:3613: unused method 'AddModule' (60% confidence) - Workspace/DscBuildData.py:3650: unused method 'AddPcd' (60% confidence) - Workspace/InfBuildData.py:117: unused attribute '_TailComments' (60% confidence) - Workspace/InfBuildData.py:126: unused attribute '_BinaryModule' (60% confidence) - Workspace/MetaDataTable.py:114: unused method 'IsIntegral' (60% confidence) - Workspace/MetaDataTable.py:218: unused method 'GetFileTimeStamp' (60% confidence) - Workspace/MetaDataTable.py:230: unused method 'SetFileTimeStamp' (60% confidence) - Workspace/MetaDataTable.py:298: unused method 'GetCrossIndex' (60% confidence) - Workspace/MetaFileParser.py:161: unused attribute '_FileDir' (60% confidence) - Workspace/MetaFileParser.py:1187: unused method '_DecodeCODEData' (60% confidence) - Workspace/MetaFileParser.py:1796: unused attribute '_RestofValue' (60% confidence) - Workspace/MetaFileTable.py:31: unused attribute '_NumpyTab' (60% confidence) - Workspace/WorkspaceDatabase.py:136: unused class 'TransformObjectFactory' (60% confidence) - Workspace/WorkspaceDatabase.py:159: unused attribute 'TransformObject' (60% confidence) Signed-off-by: Pierre Gondois

BaseTools: Add support for mingw-w64

2025-06-07T17:56:04+00:00

Adds support for building the C language BaseTools for Windows using toolchains based on mingw-w64. Mingw-w64 is a collection of header files, libraries, and tools that when combined with a compiler enable development of Windows software. Mingw-w64 is a fork of the original MinGW (Minimalist GNU for Windows). Most active development on MinGW has ceased and mingw-w64 is now the actively maintained successor. Mingw-w64 provides a libc implementation built on top of Microsoft's UCRT (Universal C Runtime) with all nessesary compiler bindings needed to support the C++11 feature set. Modern mingw-w64 development appears to have coalesced around MSYS2, which produces a distributions of both GCC and LLVM/Clang that use mingw-w64 to target the Windows OS. This MSYS2 Clang distribution has a UNIX-like directory layout and includes Windows binaries of GNU Make. Combined with the open source licensing, MSYS2's Clang distribution is a highly attractive choice as an alternative Windows SDK for open source projects such as TianoCore. If one wishes to use EDK II to build UEFI firmware on the Windows platform, then the C BaseTools need to be compiled as Windows applications. This includes the PcdValueInit.exe program, which needs to be recompiled every time a firmware build is run in order to regenerate the initial values for structured PCDs. Currently, BaseTools only supports the Visual C++ toolchain on the Windows platform. The following new features have been added to enable usage of the toolchains derived from mingw-w64: - Fixes to the BaseTools C source code to support the use of a GCC-style compiler on the Windows OS. - The GNU Make-style Makefiles for the C BaseTools have been modified to support Windows. Both GCC + mingw-w64 and Clang + mingw-w64 have been tested and confirmed to build a working BaseTools. - BaseTools now supports generating GNU Make-style Makefiles on the Windows platform for the purpose of building firmware. - edksetup.bat has been modified to optionally build BaseTools via mingw-w64. There is no impact to the existing support for Visual C++ and Visual C++ remains the default toolchain. Usage Instructions: For the vast majority of users, the only system setup change nessesary to use a mingw-w64 toolchain is to set the BASETOOLS_MINGW_PATH to the directory containing the desired mingw-w64 based toolchain. A new command line argument has been added to edksetup.bat: Mingw-w64 If this command line argument is set, then the script will set the BASETOOLS_MINGW_BUILD environment variable. The user can also opt to set this environment variable manually before running edksetup.bat If BASETOOLS_MINGW_BUILD is defined, then the BASETOOLS_MINGW_PATH environment variable must point to the directory containing the mingw-w64 toolchain. If CLANG_BIN is not defined and %BASETOOLS_MINGW_PATH%\bin\clang.exe exists, then edksetup.bat will set CLANG_BIN=%BASETOOLS_MINGW_PATH%\bin\ This removes the requirement to configure the CLANG_BIN environment variable manually in order to run a CLANGPDB or CLANGDWARF build if one has the MSYS2 Clang distribution installed. If one wishes to use a different copy of Clang (for example official LLVM binaries) to build firmware and only use the MSYS2 Clang to build BaseTools, then one can continue to set the CLANG_BIN environment variable, same as before. I have tested the MSYS2 Clang distribution against the official LLVM distribution and can confirm that if the compiler version is the same the emitted machine code is identical between the two. Interestingly, the MSYS2 Clang distribution emits the path to the PDB file using "/" as the path seperator instead of "\". That appears to be the only difference in output. Therefore, using the MSYS2 Clang distribution to compile firmware seems a reasonable choice. If CLANG_HOST_BIN is not defined and BASETOOLS_MINGW_BUILD is defined and %BASETOOLS_MINGW_PATH%\bin\mingw32-make.exe exists, then edksetup.bat will add %BASETOOLS_MINGW_PATH%\bin\ to the PATH and set CLANG_HOST_BIN=mingw32- This enable usage of the GNU Make included in the mingw-w64 toolchain to build firmware in addition to BaseTools. if BASETOOLS_MINGW_BUILD is not defined, edksetup.bat will continue to set CLANG_HOST_BIN=n, which uses nmake to build firmware. This behavior can be overridden by manually setting the value of CLANG_HOST_BIN before executing edksetup.bat if one wishes to use a specific Make utility for the CLANGPDB/CLANGDWARF toolchains. References: - https://www.mingw-w64.org/ - https://www.msys2.org/ Co-authored-by: Sandesh Jain Signed-off-by: Nate DeSimone

BaseTools: Fix Macro Expansion on Machine Architecture for Components

2025-05-09T01:01:43+00:00

BaseTools currently does not expand macros for component architecture when nested !include directives are used. This breaks use cases like [Component.$(DXE_ARCH)]. The fix is to add explicit macro expansion when computing the Arch value for component lines in DscParser. Signed-off-by: Nate DeSimone

BaseTools: Dump library dependency chain on build failure

2025-04-08T08:40:49+00:00

When a module M depends on L1, which depends on L2, which depends on L3, the build fails when the library instance of L3 cannot be found according to the library class-instance mapping configuration specified in the DSC file. When such failure happens, the build tool only prints that the instance of L3 required by module M cannot be found. But it does not tell how L3 is required by M. The change enhances build tool to print the entire dependency chain when such failure happens. With the change, the new error message will be as follows: (...): error 4000: Instance of library class [L3] is not found for module [M], [L3] is: consumed by consumed by Signed-off-by: Ray Ni

BaseTools: Typo fixes

2024-12-11T01:00:21+00:00

Some in error messages, some in local variable names. Signed-off-by: Dionna Glaze

BaseTools: InfBuildData: Fix Private value retrieval

2024-07-04T11:55:25+00:00

Update retrieval of private guids, protocols, or ppis from a package's declaration file to use the original path of the module's INF file rather than the current path. When building the same module multiple times in the same INF (by override the define's FILE_GUID), a temporary instance of the module is generated outside the package, causing the retrieval of private values to fail as the check to access private values is done by verifying the module to build, is inside the package. Signed-off-by: Joey Vagedes Cc: Rebecca Cran Cc: Liming Gao Cc: Bob Feng Cc: Yuwei Chen