supervacuus
commented
1 week ago Unfortunately, a recent crashpad update (I believe it was 0.7.6) includes changes to mini chromium which now requires C++20 features like std::ranges. I can't see a way to conditionally make mini chromium use pre-C++20 standards.
While we use a getsentry fork of crashpad, we don't use one for mini_chromium (and instead point the submodule to the upstream Google repo), so whenever crashpad updates its code based on mini_chromium changes (or vice versa, whoever is the driver), we go with the flow. crashpad doesn't generally consider build-tool adoption as a limiting factor since they are their primary user, let alone providing build parameters to minimize their effect.
This is a much bigger topic for Sentry, even though no clear boundary has yet been defined on when to fork mini_chromium for build-tooling compatibility.
This effectively hinders adoption and makes it impossible for a large number of projects out there to upgrade beyond sentry-native 0.7.6 as they cannot move on from C++17 yet, short of mirroring and patching mini chromium.
I fully understand this issue. Sadly, "mirroring and patching" mini_chromium won't suffice since you might also have to track the related changes in crashpad. This is essentially the effort of maintaining an additional transitive dependency fork for Sentry, too, so I cannot guarantee this will happen.
CC: @kahest.
sbhorvatic
Unfortunately, a recent crashpad update (I believe it was 0.7.6) includes changes to mini chromium which now requires C++20 features like std::ranges. I can't see a way to conditionally make mini chromium use pre-C++20 standards.
This effectively hinders adoption and makes it impossible for a large number of projects out there to upgrade beyond sentry-native 0.7.6 as they cannot move on from C++17 yet, short of mirroring and patching mini chromium.