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.
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?
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
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. )_
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.
