Patch additional sysconfig values such as clang at install time

[samypr100]

Summary

Minor follow up to #9905 to patch clang with cc.

Implements the replacements used in sysconfigpatcher, namely

DEFAULT_VARIABLE_UPDATES = {
    "CC": WordReplace("clang", "cc"),
    "CXX": WordReplace("clang++", "c++"),
    "BLDSHARED": WordReplace("clang", "cc"),
    "LDSHARED": WordReplace("clang", "cc"),
    "LDCXXSHARED": WordReplace("clang++", "c++"),
    "LINKCC": WordReplace("clang", "cc"),
    "AR": "ar",
}

Test Plan

Added an additional test. Tested local python installs.

Related traces

TRACE Updated `AR` from `/tools/clang-linux64/bin/llvm-ar` to `ar`
TRACE Updated `CC` from `clang -pthread` to `cc -pthread`
TRACE Updated `CXX` from `clang++ -pthread` to `c++ -pthread`
TRACE Updated `BLDSHARED` from `clang -pthread -shared -L/tools/deps/lib` to `cc -pthread -shared -L/tools/deps/lib`
TRACE Updated `LDSHARED` from `clang -pthread -shared -L/tools/deps/lib` to `cc -pthread -shared -L/tools/deps/lib`
TRACE Updated `LDCXXSHARED` from `clang++ -pthread -shared` to `c++ -pthread -shared`
TRACE Updated `LINKCC` from `clang -pthread` to `cc -pthread

Pending Discussion Items

#9905 (comment)

[zanieb]

I would be surprised if we replaced clang with cc on a system with clang but not cc. Is that silly?

[samypr100]

I would be surprised if we replaced clang with cc on a system with clang but not cc. Is that silly?

Fair, on the other hand I rather find cc to be more pervasive than clang. Even on cases where say gcc is not installed but clang is, cc would often point to clang.

I think this approach would also help systems that have gcc installed (or others) but not clang as cc would be interopable with either, unless we really want users under all cases to have clang installed on their system which is harder in some environments where you can't control the toolchains provided.

[charliermarsh]

@mitsuhiko did say that this was the most impactful of the sysconfig patches so tagging him.

[zanieb]

A relevant comment at astral-sh/python-build-standalone#210 (comment) too

[samypr100]

A relevant comment at indygreg/python-build-standalone#210 (comment) too

Good insights, at least from my perspective I see a unique distinction between python-build-standalone goals and uv with regards to these types of modifications. For example, I can see the strong desire in python-build-standalone to maintain ground truth / pristine nature of the builds (avoid modifying anything beyond what's absolutely necessary) for a lot of reasons. Given that uv is a consumer of python-build-standalone, I think uv is the ideal place to make these type of minor modifications to the downloads in order to achieve the desired level of interopability with the end user's system.

[charliermarsh]

What if we test for clang, and rewrite to gcc if it's not present?

[zanieb]

Why prefer clang / gcc over cc? Just wondering. I think it is pretty common for it to be linked?

[charliermarsh]

Oh sorry. I guess cc is fine. What's the problem with just using cc?

[zanieb]

Is there one? haha

It might break my system, I alias that to cargo check 😭 but I kind of imagine build commands don't invoke a shell.

I think cc is really reasonable, honestly.