Tianocore/edk2.git/BaseTools/toolsetup.bat, branch dependabot/github_actions/actions/setup-python-7

BaseTools: Remove VS2017 support

2026-06-30T21:42:50+00:00

Removes Visual Studio 2017 support from BaseTools. Newer toolchains (VS2019, VS2022, and VS2026) are supported in its place. This removes the VS2017 toolchain definitions from tools_def.template, the VS2017 environment setup logic in toolsetup.bat, set_vsprefix_envs.bat, and get_vsvars.bat, and the VS2017 configuration in the WindowsVsToolChain build plugin. Signed-off-by: Michael Kubacki

BaseTools: Remove VS2015 support

2026-06-30T21:42:50+00:00

REF: https://github.com/tianocore/edk2/issues/12490 Removes Visual Studio 2015 support from BaseTools since mainstream support ended on October 13, 2020 and extended support ended on October 14, 2025. Signed-off-by: Michael Kubacki

BaseTools: Add VS2026 support.

2026-01-07T20:19:12+00:00

Adding tools_def for VS2026. Update WindowsVsToolChain to support VS2026. Update set_vsPrefix_envs and toolsetup and edksetup to support VS2026. Signed-off-by: Daniel Grobert

BaseTools/toolsetup.bat: Set IASL_PREFIX when using Mingw-w64 on Windows

2025-07-10T00:45:13+00:00

If IASL_PREFIX is not already defined, then edksetup.bat should set it. This unifies the behavior between Visual Studio and Mingw-w64. Signed-off-by: Nate DeSimone

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

Update CI to VS2022

2024-12-10T23:42:09+00:00

This PR updates the CI pipelines to use VS2022 instead of VS2019 as that is the latest supported VS toolchain on edk2. Continuous-integration-options: PatchCheck.ignore-multi-package Signed-off-by: Oliver Smith-Denny

BaseTools: Remove Pip BaseTools

2024-09-10T00:41:53+00:00

BaseTools was moved out to a separate repo and consumed as a pip module by edk2 CI. This process has not led to the desired goals of doing so, so this patch removes the pip based BaseTools from edk2 CI. The original goal of moving BaseTools to a pip module was primarily to speed up the development process, as the old edk2 mailing list was slow. However, with edk2 moving to PRs, it now actually slows the BaseTools development process to have to do a PR in another repo, publish the module, and then make a PR in edk2 to consume the new BaseTools. It also holds up using the features in a new BaseTools in other PRs. There were other goals of moving, such as allowing projects to use the BaseTools outside of edk2. This can still be accomplished outside of this PR, this PR simply stops edk2 CI from using the pip module. Continuous-integration-options: PatchCheck.ignore-multi-package Signed-off-by: Oliver Smith-Denny

BaseTools: Add VS2022 support.

2024-07-08T16:50:21+00:00

Adding tools_def for VS2022. Update WindowsVsToolChain to support VS2022. Update set_vsPrefix_envs and toolsetup and edksetup to support VS2022. Signed-off-by: Aaron Pop

BaseTools: toolsetup.bat always execute PYTHON_HOME

2023-05-29T01:34:28+00:00

Ideally behavior is like below order that can support one local build machine, clone multiple Edk2, some of edk2 repo use old tag and some of edk2 repo use new tag, they can both support on one machine. 1. if defined PYTHON_COMMAND only - use PYTHON_COMMAND = user assigned 2. if not defined PYTHON_COMMAND, auto detect py -3 - use PYTHON_COMMAND = py -3 3. if defined PYTHON_COMMAND and PYTHON_HOME, use PYTHON_COMMAND - use PYTHON_COMMAND = user assigned 4. if defined PYTHON_HOME only, - use PYTHON_COMMAND = %PYTHON_HOME%/python.exe SCRIPT_ERROR should return for paraent batch file to consume for error handle. Cc: Rebecca Cran Cc: Liming Gao Cc: Bob Feng Cc: Yuwei Chen Signed-off-by: Gua Guo Reviewed-by: Rebecca Cran

BaseTools: only print the environment once in toolsetup.bat

2023-05-11T02:14:12+00:00

Avoid printing %PATH% twice: move the printing of the environment down to print_python_info. Signed-off-by: Rebecca Cran