Failing builds, failing CI

Could it be the our boost problems (see also Boost – fail to compile on macOS 14.1.1) are also behind the breaking x64 mac build that’s crippled CI (detail)? [Update: the failing CI test has been temporarily patched by building with boost 1.76]

The boost version problem is increasingly an impediment to multiple people trying to contribute, so it would be great to prioritize resolving it. There’s a proposed upgrade to boost already on offer (there’s already a slightly newer boost version).

I made some lame attempts at patching the CI workflow using some build flags that at least have contributors hobbling along, but no luck… this isn’t my wheelhouse, unfortunately.

1 Like

Did you see this Fix boost version for macOS use system libraries build by capital-G · Pull Request #6320 · supercollider/supercollider · GitHub its got CI working, just need to rebase. Not a full fix, but a temporary solution until the boost update.

1 Like

Good timing, nice to have this temporary fix for CI at least … thx @dscheiba and @jordan :slight_smile:

I know the the boost version bump isn’t trivial, but will be great to have that behind us!

Hmmm, so because that updated action script lives in the workflows directory, all PRs have to be updated/rebased in order to successfully re-run the broken test, right?

That is the only way I’ve been able to get it to work. I am not familiar with all the magic github stuff though.

Should also point out I’ve had inconsistent CI failures for server plugins.

I started a branch in which I replaced boost::filesystem with std::filesystem.
std::filesystem became a thing in C++17 by adapting most of the boost implementation, and although cppreference says

The boost implementation is currently available on more compilers and platforms than the C++17 library.

I think it is fair is an interesting experiment to get rid of boost::filesystem as SC is officially targeting C++17.
So in theory this should not be a problem, but mingw breaks because it only supports C++17 in an experimental stage - I have no access to a windows machine to inspect it further and debugging it via CI is a bit nerve-wrecking. I’ve seen some reports that msys2 is to be preferred these days, but also that SC does not officially support mingw?

Nonetheless, bumping to boost 1.83 (last major version on debian) became afterwards an easy task (see Comparing std-filesystem...upgrade-boost-183 · capital-G/supercollider · GitHub), though I had to drop GCC7 which is from 2017.
On the other hand I got a passing CI on macOS 14 without adjusting the compiler, I’ll try it out tomorrow on a native macOS 14 machine because I heard that the build still creates problems on a physical machine.
I haven’t applied any performance tweaks on it yet though.
I think it could be very interesting because we most likely will need to support more ARM builds and having an up-to-date toolchain is beneficial, as it already breaks our CI.

It is my first dive into boost and cmake, so I don’t know if it will pass any standards by the sc-devs as there is already a (somehow abandoned :?) PR which bumps boost, but at least I have learned something new about linking in CPP and boost in general :slight_smile:

Before any rebasing please wait on adjust trueAt/falseAt documentation and tests to change of behaviour by telephon · Pull Request #6321 · supercollider/supercollider · GitHub which fixes a test in the testing suite^^


In the CMake file, C++11 is currently enforced for the Intel compiler. However, since the Intel compiler supports C++17, it might be worth reconsidering that and updating it.

Is it necessary to support such outdated compiler versions in the CI? What are the important use cases for maintaining support for older compilers? Older systems can always use slightly older versions of sc.

C++20 is being rapidly adopted in various industries. While we don’t frequently change the codebase, it’s important to move forward when it aligns with the project’s goals and context. Upgrading to a newer C++ standard (c++17 in this case) would make more sense than supporting legacy compilers in the develop branch. I think…

I’ve heard complaints about compilation time here. For example, c++20 modules may help with this, modules do not need to be reparsed every time, contrary to header files. (I’m not saying to move to it, I’m just giving a hypothetical example where would make sense to adopt recent standards etc. )_

At the time of writing, the only compiler that fully implements modules is MSVC… See C++ compiler support -

Also be aware that using newer C++ library features can be a bit problematic because these must be available in the libstdc++ on the user’s machine. macOS, for example, is notoriously slow with updating their libstdc++; while AppleClang might already support all C++x language features, certain library features might still be missing. It can be quite frustrating.

Just be aware that Apple’s libstdc++ only supports std::filesystem from macOS 10.15 onwards. In general, their libstdc++ is always lagging behind. See my post above.

Yes, it’s experimental in gcc and cmake. It was not a proposal for sc.

Boost crew talked about using modules, so maybe eventually it will just happen Boost mailing page: So.... what are we going to do about modules?

Screenshot 2024-05-30 at 11.44.18
Let’s goooo

Thx @dscheiba & @julian

1 Like