dolphin
dolphin copied to clipboard
Enforce minimum supported versions of GCC and Clang
With the move to C++20, and various people wanting to clean up the codebase to use the fancy new features, many PRs have run into problems older versions of clang running on buildbots.
It would be very helpful to actually define and enforce a minimum version of Clang/GCC so that it's clear what C++20 features contributors are allowed to use. Additionally... enforcing it in cmake gives users clear feedback about what's wrong before they even start, instead of random compile errors.
We already have an explicit minimum required version of Visual Studio, so it's not too outrageous. And various implicit minimum requirements on other versions.
Why not feature detection?
That doesn't really answer the question of "what C++20 features are we allowed to use", contributors would have to remember to add feature detection when using new C++20 features, and we would end up implicitly dropping support for versions of compilers without realising it.
What versions?
I've chosen Clang 11 as a minimum because that's the version in the latest stable release of FreeBSD. And we have a FreeBSD builder (which currently all the way back on Clang 6, released March 2018, so no wonder it's been unhappy about new C++20 syntax). It's also the minimum for (partial) support of consteval
.
And GCC 10 seems to be roughly equivalent. Also the minimum for consteval
. Both were released in 2020.
@endrift are you happy updating the freebsd builder to FreeBSD 13.0 or 13.1?
Or should we do something different?
Yeah, lemme do that in a bit. Might be a little tricky but I'll try.
For the GCC version, there is an argument to be made that since we don't have a GCC 10.x builder, that we should skip over it and just require the GCC 11.x that our ubuntu uses.
I'm not sure how much extra distro compatibility GCC 10.x gains us.
- Ubuntu's releases skips straight from gcc 9 to gcc 11
- Debian's latest stable release is on gcc 10 (our Debian builders use clang)
- Fedora is uses gcc 11 on their oldest still supported release.
FreeBSD apparently updated to Clang 13 with the 13.1 release and didn't mention it in their release notes. But I think we should stick with clang 11 and GCC 10 as our minimums for now (especially with stable Debian still on GCC 10)
The FreeBSD buildbot has been updated to 13.1
The latest steamrt used for games (version 1, 'scout') only has gcc-9, which is annoying. It might be possible to just install a newer gcc if we set up a steamrt build worker in the future.
This isn't something we have to worry about right now, anyway.
Compiler shouldn't be a huge issue. It's a runtime, not a build-time. We don't want to be restrained to the compiler version it uses anyway.
However.... that might put some strain on our minimum libstdc++ version. That's a way less fixable problem. Even if we do nothing else, we might want to set up a builder targeting scout now so that we will get errors if people try to use c++20 library features that it doesn't support.
After the minimum GCC version is increased, I have seen a couple of comments around the codebase that can be addressed by this, such as in ShaderGenCommon.h:
// The second template argument is needed to avoid compile errors from ambiguity with multiple
// enums with the same number of members in GCC prior to 8. See https://godbolt.org/z/xcKaW1seW
// and https://godbolt.org/z/hz7Yqq1P5
So what's the status here?
GCC 11 begins GCC's (partial) support for modules. Whether Dolphin Emulator should or should not begin using modules yet is open for debate. I personally want to begin experimenting with modules in the Common namespace in the near future.
I think GCC 12 is what I'd need for #11057, not sure about clang.
Oh dang, you beat me to it! Well best of luck to you, then.
Personally, I'm a little uneasy about pushing to gcc 12. Debian stable is only shipping with gcc 10.
I suppose we can merge this PR as is, then I can raise the minimum required versions in #11057.
FYI, Valve has given us access to the ability to use a newer steam-runtime ("sniper", based on Debian 11), so Linux builds for Steam are no longer a problem.
I'll ask again, what's the hold up here?
I think there is a desire for a Steam Deck buildbot. Also, Android's buildbot still has an outdated stdlib, lacking <concepts> last I checked and also std::bit_cast (though it is not alone in that second one). I would also appreciate an update on this.
The Steam Linux runtime is no longer a blocker for this. We've been given access by Valve to a newer version that is based off Debian 11.
Also, Android's buildbot still has an outdated stdlib, lacking
last I checked and also std::bit_cast (though it is not alone in that second one).
The Android buildbot automatically fetches whatever SDK version is specified in the dolphin git repo. Though I suspect that not even the latest Android SDK has a recent enough stdlib for this...
It is pretty simple to create a "Future" header for std::bit_cast thanks to how old the compiler built-in is for the three major compilers. See: #11153. This has also been how I worked around <concepts> being MIA for Android. IMO, this is the way forward until every supported platform gets up to speed with C++20.
What is the prerequisite or milestone this PR is waiting on? Are we using C++20 or not? I'm sorry if this has already been answered in the IRC; I do not have anything set up to see what has been said while I am away.
Under the current Dolphin master (45b55f7ccd19a8f71c7b98d14f00668932a3bf50), it seems GCC 10 or Clang 12 (or Apple Clang 13, as reported by Dentomologist on IRC) is required to build Dolphin. GCC 10 got required since 02a967f78625ce226c0590948d49f29d6e35ebe1 and Clang 12 (/Apple Clang 13) got required since 154cb4f722a9996a4134463e64c85c6bfa25d8bf (Clang 11 and back get unhappy about the template deduction here).
Ok, I think I've addressed all review feedback.
What's the status on this?