C++17 equivalent of previous Autoconf check that we got from the [Autoconf Archive](https://www.gnu.org/software/autoconf-archive), which has since been factored into two m4 files:
* [ax_cxx_compile_stdcxx](https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx.html) * [ax_cxx_compile_stdcxx_17](https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx_17.html)
I didn't look to see if C++11 is mentioned in any docs and update them, feel free to modify to this PR to fix them, or mention in comments and I'll try and fix. You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/2862
-- Commit Summary --
* Update C++ compiler check to require C++17
-- File Changes --
M configure.ac (2) A m4/ax_cxx_compile_stdcxx.m4 (962) D m4/ax_cxx_compile_stdcxx_11.m4 (142) A m4/ax_cxx_compile_stdcxx_17.m4 (35)
-- Patch Links --
https://github.com/geany/geany/pull/2862.patch https://github.com/geany/geany/pull/2862.diff
@elextr approved this pull request.
Thanks for that.
LGBI as much as I know.
And it indicates that AT doesn't even check for compiler standards, its a separate m4, so I was able to add to my AT hate list which is long :grinning:
Doesn't a check only really useful if there is a fallback? If we fail hard either way, why add a check?
This should be a failure in configure, hopefully with a message, instead of a compile failure half way through make.
Yeah, as @elextr mentioned, the reason for the check is for an early failure with a message explaining the compiler isn't supported.
Another way to do it would be to do a compile-test for only `std::string_view` to also support non-C++17 compilers which might have already supported `std::string_view`, but then that would have to be updated for each new C++17 type/function we use, and especially with newer Scintilla 4/5 coming, probably LOTS of stuff.
I suggest using this, @kugel- has already made a PR for Scintilla 5 and who knows what that needs.
Of course its not _just_ the compiler, but also the standard library (which is where string_view lives) that needs to be modern enough, but the compiler is possibly a proxy for that ... maybe.
I just investigated this Mint (ie Ubuntu LTS based) system that has been allowed to handle compilers itself, it has gcc 8-10 available in the repos with 9.3 installed by default, and libstdc++ 8-10 available but 10.3 installed by default, interesting, I guess its ABI compatible with 9.3 so it can still be used with a 9.3 compiler but benefit from the bugfixes/additions. It also has clang 8-12 available with clang 10 installed by default and libc++ 8-12 available, but none installed. So clang is using libstdc++ here. All are Ubuntu packages, so I would expect Ubuntu LTS systems to be the same.
So I suggest we use this as "reasonable efforts, feel free to contribute better tests if you think they are needed".
Do we need to copy the .m4 files? Shouldn't autogen.sh pull them?
The m4 files are downloaded from the Autoconf archive, they aren't shipped with Autoconf where they would be copied from the system directory to the local m4 directory.
There is a "autoconf-archive" package for Debian, Arch and probably most other distros.
Does autoconf find the macros automatically if the archive is installed?
Anyway this is just an upgrade of the existing C++11 test macros, not a new thing. If somebody wants to take macros out and require a new dependency that should be a separate PR where it can be discussed.
@b4n commented on this pull request.
@@ -0,0 +1,962 @@
+# =========================================================================== +# https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx.html +# =========================================================================== +# +# SYNOPSIS +# +# AX_CXX_COMPILE_STDCXX(VERSION, [ext|noext], [mandatory|optional]) +# +# DESCRIPTION +# +# Check for baseline language coverage in the compiler for the specified +# version of the C++ standard. If necessary, add switches to CXX and +# CXXCPP to enable support. VERSION may be '11' (for the C++11 standard) +# or '14' (for the C++14 standard).
Not ours to worry about, but the doc lacks mentioning C++17 -- although the macro itself does handle it.
I don't have a non-c++17 compiler to test, if there are no other objections or alternatives will merge it in a week or so.
@b4n approved this pull request.
Just tested with Debian Buster's regular g++ (8.3) which works, and ag++ wrapper hack (for it to fail): ```python3 #!/usr/bin/env python3
from os import execvp from sys import argv
args = ['g++'] for arg in argv[1:]: if arg.startswith('-std='): continue # or: arg = '-std=gnu++11' args.append(arg) execvp(args[0], args) ``` And `CXX=/tmp/hack++ ./configure` and it does trigger a failure.
So LGTM if we indeed do need C++17 already.
@b4n yeah, the new Julia lexer uses std::string_view which is C++17 and was causing G-P Travis failures until the distro version was updated to a modern enough one to have C++17. And of course #2867 as soon as the next release is done.
Merged #2862 into master.
@codebrainz thanks
github-comments@lists.geany.org