[hartwork]

Related to #246

Was including…

• [0.4.x] libvisual: Fix palette use-after-free (when switching actors) #214
• [0.4.x] libvisual + libvisual-plugins: Require a C++11 compiler #276
• [0.4.x] libvisual-plugins: Resolve use of function "mremap" in input plug-in "mplayer" (e.g. for macOS) #277
• [0.4.x] libvisual-plugins: Compile and link against OpenGL and GLU in a more portable way (e.g. for macOS) #278
• [0.4.x] libvisual-plugins: Make input plugin "portaudio" fall back to mono as needed (e.g. for macOS) #279
• [0.4.x] libvisual-plugins: Fix compile error for actor "gforce" (e.g. for macOS) #290

… previously.

[hartwork]

@kaixiong rebased onto latest 0.4.x with #214 merged now, ready for review. I can extract smaller pull requests from this and rebase again after their merge, if you see value in that.

[hartwork]

@kaixiong rebased onto latest 0.4.x now, down to 2 commits.

[hartwork]

@kaixiong should I extract the last G-Force piece here to a dedicated pull request? Anything else in need of adjustment?

[kaixiong]

@kaixiong should I extract the last G-Force piece here to a dedicated pull request? Anything else in need of adjustment?

@hartwork That would be good, thanks.

[hartwork]

@kaixiong should I extract the last G-Force piece here to a dedicated pull request? Anything else in need of adjustment?

@hartwork That would be good, thanks.

@kaixiong here you go: #290

[hartwork]

@kaixiong now rebased off #290 onto latest 0.4.x.

[kaixiong]

@hartwork Digressing a bit but do we need to cover this many compiler versions? I welcome the idea but I feel that the time spent on CI is not scaling well.

[hartwork]

@kaixiong do you mean scaling well as in human-perceived CI runtime or as in total machine resource usage?

On other projects (with Python) where I want to be covered against surprises with Python versions in 3.7, 3.8, 3.9, 3.10, 3.11 I often cover the oldest supported and the most recent one but not the intermediates, i.e. 3.7 and 3.11 in that case, and that works okay. However our situation in Libvisual is that we have multiple macOS versions (more dimensions) + developers not using macOS (extra blindness and value) + different past errors than found by Linux CI (also extra value). We can trim this down more but I wonder at what loss and what value.

What do you think?

[hartwork]

@kaixiong PS: Three more tiny notes:

• I have not added/used macos-10.15 anywhere because it's already deprecated (in the eyes of https://github.com/actions/runner-images)
• (This is already far from a complete coverage of all combinations.)
• The matrix entries I'd be least reluctant to give up are GCC 10 and GCC 11 (because we'll still have GCC 9 @ macos-11 and GCC 12 @ macos-12).

[hartwork]

@kaixiong what do you think?

[kaixiong]

@hartwork, I think the additional build actions for MacOS are okay.

I was mostly concerned if we're going to do the same for other platforms (OS+compiler combos). That would have a combinatorial/multiplicative effect. If we start adding other kinds of validation (UBSAN, ASAN) in the future, it's going to take even longer.

[hartwork]

@kaixiong cool! 👍