detecting clang in configure.ac

[igalic]

Bug report

Bug description:

There are several attempts in configure.ac to detect what the compiler we're dealing with actually is:

dnl detect compiler name
dnl check for xlc before clang, newer xlc's can use clang as frontend.
dnl check for GCC last, other compilers set __GNUC__, too.
dnl msvc is listed for completeness.
AC_CACHE_CHECK([for CC compiler name], [ac_cv_cc_name], [
cat > conftest.c <<EOF
#if defined(__INTEL_COMPILER) || defined(__ICC)
  icc
#elif defined(__ibmxl__) || defined(__xlc__) || defined(__xlC__)
  xlc
#elif defined(_MSC_VER)
  msvc
#elif defined(__clang__)
  clang
#elif defined(__GNUC__)
  gcc
#else
#  error unknown compiler
#endif
EOF

if $CPP $CPPFLAGS conftest.c >conftest.out 2>/dev/null; then
  ac_cv_cc_name=`grep -v '^#' conftest.out | grep -v '^ *$' | tr -d ' 	'`
else
  ac_cv_cc_name="unknown"
fi
rm -f conftest.c conftest.out
])

or this,

case $CC in
    *clang*)
        cc_is_clang=1
        ;;
    *)
        if $CC --version 2>&1 | grep -q clang
        then
            cc_is_clang=1
        else
            cc_is_clang=
        fi
esac

We then have a bunch of tests against $CC:

if test "$Py_LTO" = 'true' ; then
  case $CC in
    *clang*)

(most BSDs patch this code to say *clang*|cc))

if test "$ac_cv_gcc_asm_for_x87" = yes; then
    # Some versions of gcc miscompile inline asm:
    # http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46491
    # http://gcc.gnu.org/ml/gcc/2010-11/msg00366.html
    case $CC in
        *gcc*)

etc…
For gcc we actually have a special variable, $GCC, except it doesn't seem to reliably work:

if test "${OPT-unset}" = "unset"
then
    case $GCC in
    yes)
        if test -n "${cc_is_clang}"
        then

How to fix this?

autoconf (2.71?) seems to automatically detect GCC, setting a convenient $GCC variable. For clang, we can either reuse the $cc_is_clang code, moving it just after AC_PROG_CC, setting a $CLANG variable, or reuse the code that sets $ac_cv_cc_name, again, maybe setting a $CLANG variable for convenience.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Other

[erlend-aasland]

It seems to me this is a build system enhancement rather than a bug-fix. It also reminds me that we need a modern build system for CPython.

[igalic]

I can highly recommend re-evaluating your build system every ten years, or whenever the number of developers on the project who are deeply familiar with it dips below 2%.

I can try to get this fixed in time for 3.13, but I'm afraid I don't have the skill or knowledge to replace the entire build system ;)

[erlend-aasland]

I can try to get this fixed in time for 3.13 [...]

Sure, feel free to take this on; I'll be automatically requested for review for any configure.ac changes.

[...] but I'm afraid I don't have the skill or knowledge to replace the entire build system ;)

Replacing the build system will require at least one PEP :) See prior discussions:

• https://discuss.python.org/t/what-do-you-consider-pain-points-of-todays-build-system/31815
• https://discuss.python.org/t/what-do-you-want-to-see-in-tomorrow-s-cpython-build-system/28197
• https://discuss.python.org/t/revisiting-the-case-for-cmake-as-a-primary-cross-major-plats-build-config/11758
• https://discuss.python.org/t/is-there-prior-discussion-around-the-build-system-of-cpython-itself/2813

[igalic]

I've now read all of these discussions, and am convinced that this will definitely happen in the next year or three, or failing that, within the next release or three.

As an aside, PostgreSQL recently migrated to meson. That is a pretty big accomplishment for such a big and old project.

[Ahajha]

Just injecting: Plus one vote for a newer build system, the CPython Conan recipe is rather complicated (mainly due to the Windows build). I'd be willing to give a CMake build system a shot if such a contribution would be welcome.

(Conan recipe, for those curious: https://github.com/conan-io/conan-center-index/blob/master/recipes/cpython/all/conanfile.py)

[erlend-aasland]

Duplicate of #96398.

Let's continue the discussion over there.