I believe that on Linux we devendor harfbuzz-ng, right? It would be really nice if we could do the same for Darwin.

Some weird thing happened.

https://hydra.nixos.org/job/nixpkgs/trunk/qt5.qtwebengine.aarch64-darwin

Grepping the logs of those 2 builds:

The green one:

Project MESSAGE: Using clang++ from /nix/store/3vhfsa0ysc545n970bf7jrjawp7yalcn-clang-wrapper-15.0.7/bin/clang++
clang version 15.0.7
Target: arm64-apple-darwin
Thread model: posix
InstalledDir: /nix/store/g1iqk1kj8q36zqwrmchwic7dkxmj8mq6-clang-15.0.7/bin

The red one:

Project MESSAGE: Using clang++ from /nix/store/v39c0h6xv6hvki2k1bsyp5n090q8y2bp-clang-wrapper-16.0.6/bin/clang++
clang version 16.0.6
Target: arm64-apple-darwin
Thread model: posix
InstalledDir: /nix/store/44hqr4414m3jldixkm4cq47q5pnpy83d-clang-16.0.6/bin

According to:

Clang 15 should be used, commit ab80059 broke it? @reckenrode

I believe that on Linux we devendor harfbuzz-ng, right? It would be really nice if we could do the same for Darwin.

While grepping the logs, I find use_system_harfbuzz=true args is added to the gn command in the linux build logs, but not in the darwin build.

I believe use_system_harfbuzz=true will be automatically set on linux, but not on darwin.

IIRC some of the devendoring flags only function on Linux because of weird Chromium build system stuff. But maybe this one works?

While devendoring is nice, but I think it won't fix the build because:

* -Wenum-constexpr-conversion: This is a downgradable error in clang 16, but it is planned 
  to be made into a hard error in a future version of clang. Patches are not available for 
  the version of v8 used by Chromium in Qt WebEngine, and fixing the code is non-trivial.

Need to figure out why overrideLibcxx llvmPackages_15.stdenv does not work.

Fair enough. FWIW, I think we won‘t ship Qt 5 WebEngine in 25.05 due to the upcoming EOL, so it might not be worth spending too much time on it anyway.

@K900 Maybe we should just work to drop Qt 5 WebEngine early in the cycle? There’s no reasonable expectation that the KDE people are going to be able to keep adequately on top of Chromium security backports, right?

Would be nice, but probably impractical. If someone wants to go and estimate the blast radius, that would be good though.

Well, I feel like the alternative is that we end up having to set it knownVulnerabilities a month after 25.05 release, which is all the same blast but with far more pain. Do we expect that a significant number of users will migrate off it within the next half a year?