d77efa2ebe
When collecting the required library instances for modules and libraries, included libraries will be recursed to ensure the module is built with all the libraries directly linked to it and indirectly linked to it via included libraries. Using the following scenario as an example: [LibraryClasses.common.DXE_CORE] NULL|Path/To/Library1.inf // Includes DebugLib [LibraryClasses.common.DXE_DRIVER] NULL|Path/To/Library2.inf // Includes DebugLib [LibraryClasses.common.DXE_CORE, LibraryClasses.common.DXE_DRIVER] DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf [Components] MdeModulePkg/Core/Dxe/DxeMain.inf // Includes DebugLib The DXE_CORE NULL library will be assigned a fake library class like NULL1 and the DXE_DRIVER will be assigned NULL2. The recursion logic will see NULL1 as a directly linked and will add an instance of it to the list of libraries which need to be included in the module. When DebugLib is evaluated, the recursion logic will add the libraries DebugLib depends on to the queue which includes both NULL1 and NULL2. When NULL2 is unqueued, an instance of it will also be added to the list of libraries needed to build DxeMain which now means that both NULL1 and NULL2 have been linked. NULL includes outside of module overrides are not supported according to the spec, but we do it anyways so this seems like a case which should be fixed. This change updates the recursion logic to skip evaluating NULL libraries unless they are linked directly to the module/library being evaluated. Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Yuwei Chen <yuwei.chen@intel.com> Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> |
||
|---|---|---|
| .. | ||
| AmlToC | ||
| AutoGen | ||
| BPDG | ||
| Capsule | ||
| Common | ||
| CommonDataClass | ||
| Ecc | ||
| Eot | ||
| FMMT | ||
| FirmwareStorageFormat | ||
| GenFds | ||
| GenPatchPcdTable | ||
| PatchPcdValue | ||
| Pkcs7Sign | ||
| Rsa2048Sha256Sign | ||
| Split | ||
| Table | ||
| TargetTool | ||
| Trim | ||
| UPT | ||
| Workspace | ||
| build | ||
| tests/Split | ||
| GNUmakefile | ||
| Makefile | ||
| README.md | ||
| basetool_tiano_python_path_env.yaml | ||
| sitecustomize.py | ||
README.md
Edk2 Basetools
This folder has traditionally held the source of Python based tools used by EDK2.
The official repo this source has moved to https://github.com/tianocore/edk2-basetools.
This folder will remain in the tree until the next stable release (expected 202102).
There is a new folder under Basetools BinPipWrappers that uses the pip module rather than this tree for Basetools.
By adding the scope pipbuild-win or pipbuild-unix (depending on your host system), the SDE will use the
BinPipWrappers instead of the regular BinWrappers.
Why Move It?
The discussion is on the mailing list. The RFC is here: https://edk2.groups.io/g/rfc/topic/74009714#270 The benefits allow for the Basetools project to be used separately from EDK2 itself as well as offering it in a globally accessible manner. This makes it much easier to build a module using Basetools. Separating the Basetools into their own repo allows for easier CI and contribution process. Additional pros, cons, and process can be found on the mailing list.
How Do I Install It?
By default, EDK2 is tied to and tested with a specific version of the Basetools through pip-requirements.txt.
You can simply run:
pip install -r pip-requirements.txt
This will install the required module, thought we strongly suggest setting up a virtual environment. Additionally, you can also install a local clone of the Basetools as well as a specific git commit.