Description

igalic

opened on Sep 28, 2023

Issue body actions

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

Activity

1. igalic

   added

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   on Sep 28, 2023
2. sunmy2019

   added

   buildThe build process and cross-buildThe build process and cross-build

   on Sep 29, 2023
3. AlexWaygood

   changed the title [-]detecing clang in configure.ac[/-] [+]detecting clang in configure.ac[/+] on Sep 30, 2023
4. erlend-aasland commented on Oct 4, 2023

   

   erlend-aasland

   on Oct 4, 2023

   Contributor

   More actions

   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.
5. erlend-aasland

   added

   type-featureA feature request or enhancementA feature request or enhancement

   and removed

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   on Oct 4, 2023
6. igalic commented on Oct 4, 2023

   

   igalic

   on Oct 4, 2023

   ContributorAuthor

   More actions

   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 ;)
7. erlend-aasland commented on Oct 4, 2023

   

   erlend-aasland

   on Oct 4, 2023

   Contributor

   More actions

   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
8. igalic commented on Oct 5, 2023

   

   igalic

   on Oct 5, 2023

   ContributorAuthor

   More actions

   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.
9. Ahajha commented on Mar 25, 2024

   

   Ahajha

   on Mar 25, 2024

   More actions

   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)

   Reacted by Mina Galić
10. erlend-aasland commented on Apr 12, 2024

    

    erlend-aasland

    on Apr 12, 2024

    Contributor

    More actions

    Duplicate of #96398.

    Let's continue the discussion over there.
11. erlend-aasland

    closed this as not plannedon Apr 12, 2024

Issue actions