Repository navigation
detecting clang in configure.ac #110034
Description
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
esacWe 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}"
thenHow 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
Activity
erlend-aasland commented on Oct 4, 2023
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 commented on Oct 4, 2023
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 commented on Oct 4, 2023
Sure, feel free to take this on; I'll be automatically requested for review for any configure.ac changes.
Replacing the build system will require at least one PEP :) See prior discussions:
igalic commented on Oct 5, 2023
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 commented on Mar 25, 2024
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 commented on Apr 12, 2024
Duplicate of #96398.
Let's continue the discussion over there.