toggle quoted messageShow quoted text
After remove, the supported tool chain will have its maintainer. This is a good idea.
For CLANG tool chain, CLANGPDB and CLANGDWARF supports IA32 and X64 arch only, they can run Windows/Linux/MacOs. CLANGPDB is to directly generate EFI image with PDB debug symbol, CLANGDWARF is to generate ELF image with DWARF debug symbol. CLANG35 is to support ARM and AARCH64 only. CLANG38 is to support IA32, X64, ARM and AARCH64 archs. It runs on Linux OS.
Have you more information about CLANG tool chain?
发件人: firstname.lastname@example.org <email@example.com> 代表 Sean
发送时间: 2022年5月3日 7:24
收件人: firstname.lastname@example.org; email@example.com
主题: [edk2-rfc] [rfc] Remove support for unsupported tool_chain_tags
As discussed at the weekly tools meeting, I am proposing that all
unsupported tool chains get removed from tools_def.template in the
Basetools/Conf folder (edk2/tools_def.template at master ·
The fact that VS2008 is still listed there is proof of a problem.
Many of these old tool chains are not available and if found would not
reliably work anyway (see dozens of emails on the list, most recent by
The suggestion from the tools meeting discussions is that we should
setup maintainers for each tool chain tag and any tool chain tag without
a maintainer would then be removed.
Today the CI and PR system is testing the most recent versions of VS and
GCC. As of this email that tag is VS2019 and GCC5. There has also been
a desire to add clang (clangpdb tag) to the list of CI builds but it is
currently only partially supported and needs some community effort. The
GCC5 tag might need more clarity as I know this supports many different
versions so I am not sure how to correctly communicate what is the
actual supported version. Maybe the container discussion would help
([CI] Use containers on Linux · Discussion #2732 · tianocore/edk2
(github.com) <https://github.com/tianocore/edk2/discussions/2732>) and
it could be N and N-1 on the latest container images?
Finally, the question is how to define a supported tool chain and what
are the expectations for the "maintainer". I would propose two things.
1. A category/tag created for the tool chain in the issue tracking
system and the maintainer will be the default assigned owner for
incoming bugs and is responsible for triage and resolution.
a. If all maintainers resign the community would be notified and if
no one came forward the toolchain would be dropped.
b. If the tag had a high bug count and low resolution/response rate
the toolchain maintainer role would be re-evaluated.
2. At defined points in the edk2 development process, each package is
compiled in debug, release, and noopt for the toolchain for all
supported architectures. The report is made available.
A. Suggested at minimum for each hard freeze stable tag point but
could be CI, nightly, weekly, etc.
B. Suggestion is this should somehow be automated for the CI system
and tool chains supported.
3. Update maintainers.txt to indicate tool chain maintainers
Please use this email and/or tools meeting to discuss the proposal or
becoming a toolchain maintainer.
RFC will be implemented after the may stable tag if no issues are raised.