GNU autoconf-2.70 released [LWN.net]

GNU autoconf-2.70 released

Posted Dec 9, 2020 9:14 UTC (Wed) by sandsmark (guest, #62172)
Parent article: GNU Autoconf 2.70 released

Is it actually support for c++11 (and not c++20), or did I miss anything?

to post comments

GNU autoconf-2.70 released

Posted Dec 9, 2020 13:47 UTC (Wed) by nix (subscriber, #2304) [Link] (9 responses)

It's *automatically enabling* C++11 without the caller having to do anything else. (This is probably something most users of codebases new enough to want to upgrade to Autoconf 2.70 are having to do by hand these days anyway.)

C++20 is way too new to be flipped on by default, if you ask me. Almost no codebases are ready yet.

GNU autoconf-2.70 released

Posted Dec 9, 2020 14:53 UTC (Wed) by zwol (guest, #126152) [Link] (8 responses)

GCC 10's documentation describes the C++20 support as "highly experimental, and will almost certainly change in incompatible ways in future releases". I don't think we'll be turning C++20 on by default in Autoconf before compiler support stabilizes :-)

I do regret not having had the time to get a probe for C and C++ 2017 implemented, but writing those test programs is not easy (you have to close-read both the previous and the current version of the standard to figure out exactly what changed). Our future plans involve allowing configure.ac authors to declare exactly which version of each language standard they want (the PostgreSQL folks specifically asked for this) and adding a hook that lets third-party macros contribute test programs for standard versions not supported by the base Autoconf; both of these should make life easier for people who want to stick to the bleeding edge.

Of course, for any of that to be any help at all, the next release of Autoconf needs to happen sooner than 2028...

GNU autoconf-2.70 released

Posted Dec 10, 2020 14:20 UTC (Thu) by Sesse (subscriber, #53779) [Link] (3 responses)

I assume you can't just check the value of the __cplusplus macro? C++17 even has specific feature-test macros.

GNU autoconf-2.70 released

Posted Dec 10, 2020 16:50 UTC (Thu) by zwol (guest, #126152) [Link] (2 responses)

Compilers have this nasty tendency to set the value of __cplusplus (or __STDC_VERSION__ for C) aspirationally, before they're done implementing the new version of the standard. (It makes sense on the development branch: you need the new value of the macro in place early so you can implement things that key off of it in the headers. The trouble is, then that gets into a production release before it's fully debugged.) Autoconf's test for C2011-conformant anonymous unions makes a good example of the problems we have to weed out.

"Why don't you have a separate AC_C_ANONYMOUS_UNIONS test for that?" I hear you ask. We do offer that kind of specific test, but it's intended for features that were first implemented in isolation and got rolled into a standard update later, like inline in C. If you are writing new code in C++11 or whatever, we'd like you to be able to rely on __cplusplus and not have to do a bunch of configure-time tests that are, in principle, redundant to the version of the standard you asked for.

GNU autoconf-2.70 released

Posted Dec 10, 2020 21:07 UTC (Thu) by madscientist (subscriber, #16861) [Link] (1 responses)

Or the reverse: they won't set the value at all because some aspect of the standard isn't fully supported even though most of it is supported. Visual Studio, for example, reported a value for C++98 or something until the last release or two. This makes testing __cplusplus practically useless for any portable application to see what features are available.

GNU autoconf-2.70 released

Posted Dec 19, 2020 21:15 UTC (Sat) by jengelh (subscriber, #33263) [Link]

That's where __has_cpp_attribute() comes in.

GNU autoconf-2.70 released

Posted Dec 10, 2020 15:24 UTC (Thu) by sandsmark (guest, #62172) [Link] (2 responses)

> GCC 10's documentation describes the C++20 support as "highly experimental, and will almost certainly change in incompatible ways in future releases". I don't think we'll be turning C++20 on by default in Autoconf before compiler support stabilizes :-)

I thought c++20 because that's what (some) people are slowly starting to use, and c++11 seemed weird because compilers default to c++14 (at least gcc since gcc6 default to 14 iirc). And fwiw, __cplusplus (as Sesse mentioned) is defined in the c++14 standard.

GNU autoconf-2.70 released

Posted Dec 10, 2020 16:52 UTC (Thu) by zwol (guest, #126152) [Link] (1 responses)

> c++11 seemed weird because compilers default to c++14

This is what happens when a project doesn't make a release for eight years :-(

GNU autoconf-2.70 released

Posted Dec 10, 2020 18:12 UTC (Thu) by pbonzini (subscriber, #60935) [Link]

No, *this* is what happens when a project isn't released for 8 years:

Read Autoconf 2.70 release notes
"Oh cool! Autotest improvements! Somebody else is using Autotest!"
"Uh I'm among the contributors? What did I do?"
git shortlog v2.69..
"Ah, *I* did the Autotest improvements."

GNU autoconf-2.70 released

Posted Dec 13, 2020 4:16 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

> I do regret not having had the time to get a probe for C and C++ 2017 implemented, but writing those test programs is not easy

I guess I understand the impetus behind fine-grained feature detection and verification, but I think it is just a maintenance nightmare[1]. Any new C or C++ compiler these days is going to have to emulate an existing compiler for at least some part of its lifecycle just to get past all the `#error "unknown compiler"` shenanigans that exist out there (once they're big enough, teaching the main build systems out there about your new compiler should have been on the task list by then). It basically means one needs a CMake roughly newer than your compiler, but I don't think that's *too* much of an ask at least.

It would likely mean revving up the autoconf release cycle though since platforms change all the time…

[1]In CMake, we had fine-grained feature detection for C++11, but with 14 and newer, compilers are following the standard pretty closely now and we just have release-level feature requests. These are now just gated by version checks in the compiler detection routines declaring what language versions are supported.