ClangPdbToolChain.py: Update PATH search design

[Antaeus Kleinert-Strand (antklein)]

Description

• Replace manual PATH traversal with shutil.which() for reliable Clang discovery.
• Resolve symlinks so CLANG_BIN points to the actual Clang binary directory. This prevents builds from using a symlink directory that may not contain related LLVM tools required by the toolchain.
• Clean up imports, formatting, and comments for Python style compliance.

• Impacts functionality?
• Impacts security?
• Breaking change?
• Includes tests?
• Includes documentation?

How This Was Tested

• Verified Clang discovery when clang is exposed through a symlink on PATH.
• Confirmed CLANG_BIN resolves to the real LLVM binary directory.
• Confirmed Clang version detection and a CLANGPDB build still succeed.

Integration Instructions

N/A

[mu-automation]

✅ QEMU Validation Passed

Source Dependencies

Repository	Commit
mu_basecore	c0c97a3
mu_tiano_platforms	80c15cf

Results

Platform	Target	Build	Boot	Overall Boot Time	Build Logs	Boot Logs
Q35	DEBUG	✅ success	✅ success	0m 19s	Build Logs	Boot Logs
ArmVirt	DEBUG	✅ success	✅ success	0m 14s	Build Logs	Boot Logs

Workflow run: https://github.com/microsoft/mu_basecore/actions/runs/34873079396

This comment was automatically generated by the Mu QEMU PR Validation workflow.

[Codecov Comments Bot (codecov-commenter)]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (release/202511@a13ce08). Learn more about missing BASE report.

Additional details and impacted files

@@                Coverage Diff                @@
##             release/202511    #1910   +/-   ##
=================================================
  Coverage                  ?    2.23%           
=================================================
  Files                     ?     1670           
  Lines                     ?   427108           
  Branches                  ?     5079           
=================================================
  Hits                      ?     9529           
  Misses                    ?   417495           
  Partials                  ?       84           

Flag	Coverage Δ
FmpDevicePkg	9.53% <ø> (?)
MdeModulePkg	1.65% <ø> (?)
MdePkg	5.44% <ø> (?)
NetworkPkg	0.55% <ø> (?)
PolicyServicePkg	30.42% <ø> (?)
SecurityPkg	1.56% <ø> (?)
StandaloneMmPkg	0.50% <ø> (?)
UefiCpuPkg	4.78% <ø> (?)
UnitTestFrameworkPkg	11.70% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Antaeus Kleinert-Strand (antklein)]

Related PR to push this plugin up to edk2.
tianocore/edk2#12502

[Antaeus Kleinert-Strand (antklein)]

aaronp2 Should this PR be abandoned with the fast-approaching move to release/202608 and the upstream PR for edk2?

[Michael Kubacki (makubacki)]

Antaeus Kleinert-Strand (@antklein), there are two opens about this PR that make it a bit ambiguous to me on how to move forward.

1. The PR does not have an associated issue or details in the description describing a current problem or environment blocked by not having these changes. Can you please update the description to state whether these are required to unblock an actual platform using Clang with 2511?
2. Given BaseTools: Add ClangToolChain build plugin tianocore/edk2#12502 is already in-progress and has edk2-unique changes, we should at a minimum reconcile that with these changes. Either cherry-pick this commit onto that edk2 PR branch, wait for that edk2 PR to merge and then fix up this commit so it can go to edk2 and be cherry-picked back, etc.

(2) depends on the urgency described in (1).

Imo, if this is not high priority for 2511, since the plugin is still not upstreamed yet, I suggest the edk2 PR be amended with the changes to skip extra steps to get everything cleanly merged in edk2 and then a single cherry-pick back to Mu will account for both.

[Antaeus Kleinert-Strand (antklein)]

Antaeus Kleinert-Strand (Antaeus Kleinert-Strand (@antklein)), there are two opens about this PR that make it a bit ambiguous to me on how to move forward.

1. The PR does not have an associated issue or details in the description describing a current problem or environment blocked by not having these changes. Can you please update the description to state whether these are required to unblock an actual platform using Clang with 2511?
2. Given BaseTools: Add ClangToolChain build plugin tianocore/edk2#12502 is already in-progress and has edk2-unique changes, we should at a minimum reconcile that with these changes. Either cherry-pick this commit onto that edk2 PR branch, wait for that edk2 PR to merge and then fix up this commit so it can go to edk2 and be cherry-picked back, etc.

(2) depends on the urgency described in (1).

Imo, if this is not high priority for 2511, since the plugin is still not upstreamed yet, I suggest the edk2 PR be amended with the changes to skip extra steps to get everything cleanly merged in edk2 and then a single cherry-pick back to Mu will account for both.

This affects CLANGPDB builds under WSL when clang is found through a symlink, but it is not a hard 2511 blocker because explicitly setting CLANG_BIN avoids the issue. Given that workaround, I agree the fix should be incorporated into edk2#12502 first and then cherry-picked back to Mu.

Michael Kubacki (@makubacki) Do we have a timeline for when the upstream edk2 PR will be merged? I've gone and added my comments to the PR already.

[Michael Kubacki (makubacki)]

Imo, if this is not high priority for 2511, since the plugin is still not upstreamed yet, I suggest the edk2 PR be amended with the changes to skip extra steps to get everything cleanly merged in edk2 and then a single cherry-pick back to Mu will account for both.

This affects CLANGPDB builds under WSL when clang is found through a symlink, but it is not a hard 2511 blocker because explicitly setting CLANG_BIN avoids the issue. Given that workaround, I agree the fix should be incorporated into edk2#12502 first and then cherry-picked back to Mu.

Michael Kubacki (Michael Kubacki (@makubacki)) Do we have a timeline for when the upstream edk2 PR will be merged? I've gone and added my comments to the PR already.

There is not a definitive timeline, but the Core UEFI team can prioritize reviewing and making changes. The first step is to get everything integrated into 12502 and have all conversation threads resolved.