Reduce the Emscripten build size and reduce build time by building libclang target instead of the clang target

[mcbarton]

Description

Please include a summary of changes, motivation and context for this PR.

Clang.js takes a while to build. We don't use clang.js, we just use the library. In theory we should be able to pass all Emscripten tests by building the libclang target instead of clang target. This will reduce the Emscripten cache (freeing up some very much needed space in the Github cache with the llvm 20 upgrade PR to come), and will speed up build times for developers. If the ci passes, then I will update the documentation accordingly.

Fixes # (issue)

Type of change

Please tick all options which are relevant.

• Bug fix
• New feature
• Requires documentation updates

Testing

Please describe the test(s) that you added and ran to verify your changes.

Checklist

• I have read the contribution guide recently

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 72.71%. Comparing base (993550c) to head (35bd063).
Report is 4 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #531   +/-   ##
=======================================
  Coverage   72.71%   72.71%           
=======================================
  Files           9        9           
  Lines        3618     3618           
=======================================
  Hits         2631     2631           
  Misses        987      987           

🚀 New features to boost your workflow:

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

[anutosh491]

Technically we don't need any tool (neither the js nor the wasm). For example currently how we build llvm, we build so many tools along the way like clang-repl.js/ clang-repl.wasm and none of this is put to use.

I even tried putting these to use actually. For example we build llvm-nm.js/wasm ; llvm-c++filt.js/wasm (so technically there is nothing stopping us from using these with jupyterlite's terminal). I tried using these tools there but they are far from working :|

So its not that these tools are even being built correctly, even if they are. Would be great if we could only build libclangInterpreter.a (and its static transitive libs)

[mcbarton]

So its not that these tools are even being built correctly, even if they are. Would be great if we could only build libclangInterpreter.a (and its static transitive libs)

@anutosh491 That is already done in the ci. You can build just them by swaping the clang-repl target for clangInterpreter clangStaticAnalyzerCore targets.

I thought the liblld target would exist without checking (I already knew the libclang target existed). I will investigate swapping out the lld target for a future PR