sysconfig.get_config_var("CXX") now sometimes records an absolute path

[jameslamb]

Bug description:

As a result of recent change(s) (I think #148298) configure now sometimes records an absolute path to the C++ compiler it found at build time in sysconfig.get_config_var("CXX").

Consider the following, on an x86_64 Linux system:

check-sysconfig() {
    docker run \
        --rm \
        -it $1 \
        python -c "import sysconfig; print(sysconfig.get_config_var('CXX'))"
}

$ check-sysconfig python:3.12
g++

$ check-sysconfig python:latest
/usr/bin/g++

Was this intentional? Or just a side effect of fixing something else?

If it was unintentional, I think reverting to a relative path would be preferable.

Impact

I noticed this in a project where we build CPython from source in container images using pyenv install. Those images install the GCC 14 toolset and expect that putting it earlier on PATH will be enough for processes like CMake to find it.

Until recently, that worked fine for my use cases with Python wheels building C++ DSOs using CMake + scikit-build-core:

1. CXX env var unset
2. scikit-build-core fell back to syconfig.get_config_var("CXX") (scikit-build/scikit-build-core code link)
3. that returned g++ or similar (relative path), which meant a lookup on PATH, which meant a toolset install like /opt/rh/gcc-toolset-14/root/usr/bin/g++ could be found
   (details in ci-wheel: GCC toolset not being found in CMake builds rapidsai/ci-imgs#420)

That variable now holding an absolute path now means such strategies don't work.

I don't know for sure, but suspect others were relying on a similar pattern to what I described above. Not sure but this might also affect pypa/manylinux (see its build-cpython.sh script here).

Thanks for your time and consideration.

CPython versions tested on:

3.11, 3.12, 3.13, 3.14, 3.15

Operating systems tested on:

Linux