Test basic functionality for wide variety of platforms/compilers #144
Labels
⬇️ affects: repo or tools
Affects the non-library tools or the repository itself
📁 kind: enhancement
New feature or request
💪 effort: medium
Milestone
Comments
chiphogg
added
📁 kind: enhancement
Merged
chiphogg
added a commit
that referenced
this issue
Jul 24, 2023
The job builds a single-file version of the Au library, and runs a simple test. This test is enough to reproduce the errors in #143: https://github.com/aurora-opensource/au/actions/runs/5496101666/job/14882361539 It also catches another few compiler errors on other versions of MSVC, which we fix here. The issue is that function parameters can't be used in a `constexpr` context in general. These particular parameters are monovalue types (https://aurora-opensource.github.io/au/main/reference/detail/monovalue_types/), so the compiler's being a little pedantic in enforcing this rule, but this also means that it's easy to fix the error. With this PR, we go from 0 to 1 in terms of CI jobs for "best effort" platforms. This gives us a pattern we can use for future new platforms. Helps #144.
chiphogg
added a commit
that referenced
this issue
Jul 28, 2023
We'll provide 3 tiers: full support, best effort, and assumed support. The new doc explains what these 3 tiers mean. The motivation behind this division is in part due to my experience working on mpusz/mp-units#300. That project got stalled for multiple months because I couldn't iterate locally on an issue we encountered with the MSVC compiler (which turned out to be a compiler bug!). Therefore, the compilers which _do_ let us iterate locally get the highest level of support. Next up is "anything we can make a CI job for", including several Windows/MSVC configurations. We plan to keep these passing always, although a time might come when something in this tier gets dropped because it's too painful to maintain. The final tier is "assumed support", which is just what it sounds like. I also added the new badgest to the README.md. I thought about adding a section for compiler support, but it didn't flow well, and besides, everybody understands more or less what the badges mean --- we can revisit this if and when any of them ever start failing. Fixes #144.
chiphogg
added a commit
that referenced
this issue
Aug 19, 2023
We'll provide 3 tiers: full support, best effort, and assumed support. The new doc explains what these 3 tiers mean. The motivation behind this division is in part due to my experience working on mpusz/mp-units#300. That project got stalled for multiple months because I couldn't iterate locally on an issue we encountered with the MSVC compiler (which turned out to be a compiler bug!). Therefore, the compilers which _do_ let us iterate locally get the highest level of support. Next up is "anything we can make a CI job for", including several Windows/MSVC configurations. We plan to keep these passing always, although a time might come when something in this tier gets dropped because it's too painful to maintain. The final tier is "assumed support", which is just what it sounds like. I also added the new badgest to the README.md. I thought about adding a section for compiler support, but it didn't flow well, and besides, everybody understands more or less what the badges mean --- we can revisit this if and when any of them ever start failing. Fixes #144. --------- Co-authored-by: johnzoppina <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
#143 has exposed a tooling deficiency. So far, we've assumed that simply "write correct C++14" is good enough to support everyone who's using a standard at least as recent as C++14. But that issue shows a compiler error in a product whose name includes "2019", which suggests this isn't true. It shows we're currently blind to our actual level of support for various platform/compiler combinations.
This issue has two components for a definition of "done":
As to the first, a platform/compiler is "fully supported" whenever we fulfill two conditions:
The motivation for the second condition is that working on mpusz/mp-units#300 was quite painful due to the gating MSVC jobs --- it ended up being delayed about 2 or 3 months because I had a bizarre error which I couldn't iterate on locally. (I think it turned out to be an actual compiler bug! 😅)
The second tier of support would be "best effort", where we have automatic tests to measure support for that platform, but we don't strictly require that those tests pass. If they fail, we need to make an effort to get them passing, but we won't guarantee that we'll block PRs on keeping them passing.
Currently, our only real support is for platforms that can offer a hermetic bazel toolchain, which includes two versions of clang and one of gcc. I believe we can make GitHub actions for a wider variety of platforms, including various versions of MSVC. If it's possible to run these GitHub actions locally, then we could significantly broaden the set of platforms/compilers that will be fully supported. That'll be the goal. Otherwise, we will still try to add them, but as "best effort".
The text was updated successfully, but these errors were encountered: