build(macos): configure C++ standard and ICU root

[martona]

Description

Pass the project C++ 23 standard explicitly so fetched dependencies build against modern headers. C++23 was chosen because it's already used for the sunshine target in cmake/targets/common.cmake and by the Homebrew formula in packaging/sunshine.rb, but those don't apply early enough to dependencies built through scripts/macos_build.sh. This can break when Boost falls back to FetchContent.

Point CMake at Homebrew's icu4c@78 prefix to match the dependency installed by the macOS build path. Without this, CMake can pick up inconsistent ICU headers/configuration from the Apple SDK or system paths while Boost.Locale is built from source.

Mirror the manual macOS build script in CI so the two paths stay aligned, as requested in the script comments.

Screenshot

Issues Fixed or Closed

Roadmap Issues

Type of Change

• feat: New feature (non-breaking change which adds functionality)
• fix: Bug fix (non-breaking change which fixes an issue)
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
• refactor: Code change that neither fixes a bug nor adds a feature
• perf: Code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit
• BREAKING CHANGE: Introduces a breaking change (can be combined with any type above)

Checklist

• Code follows the style guidelines of this project
• Code has been self-reviewed
• Code has been commented, particularly in hard-to-understand areas
• Code docstring/documentation-blocks for new or existing methods/components have been added or updated
• Unit tests have been added or updated for any new or modified functionality

AI Usage

• None: No AI tools were used in creating this PR
• Light: AI provided minor assistance (formatting, simple suggestions)
• Moderate: AI helped with code generation or debugging specific parts
• Heavy: AI generated most or all of the code changes

[ReenigneArcher]

I'm confused about setting CXX_STANDARD here. We already set it in cmake itself, and we always use fetch content in our CI builds, so I'm not sure this is actually an issue.

[martona]

The existing CXX_STANDARD setting applies only to the sunshine target, and it is set after dependencies/common.cmake has already added the FetchContent targets.

In my local build, Homebrew had Boost 1.90 installed, while the project requested exactly 1.89. CMake rejected the newer Homebrew Boost and fell back to FetchContent, so Boost.Locale was built as part of the project. That fetched Boost target then compiled against Homebrew’s ICU headers without a C++17+ default and failed on ICU headers using constructs like auto non-type template parameters and std::is_same_v.

Passing -DCMAKE_CXX_STANDARD=23 at configure time makes the project default visible before FetchContent targets are created. I used 23 specifically because that is already the standard requested for the Sunshine target and the Homebrew packaging path.

That said, if you prefer, setting the project-wide C++ standard near the top-level CMake before dependencies are loaded would be cleaner than passing it from the macOS scripts.

I also wouldn't be offended if you chose to reject as it is very much an edge case and easy to work around with exports in .zshrc but I doubt I'm the only one to ever run into this.

[ReenigneArcher]

I think this can probably affect Linux as well, so probably we could just set it in the top level CMakelists.txt as well as in the tests.

[martona]

Right, it probably does. Do you want me to take a crack at it?

[ReenigneArcher]

Right, it probably does. Do you want me to take a crack at it?

Yes please!

[martona]

Done. It builds cleanly on macOS, I did not test elsewhere.

[martona]

And for good measure I updated /tests and /tools as well. You did not ask for the latter, but it makes sense since they were redundant. (I missed them earlier, apologies for all the noise.)

[codecov]

Bundle Report

Changes will decrease total bundle size by 3.22kB (-0.2%) ⬇️. This is within the configured threshold ✅

Detailed changes

Bundle name	Size	Change
sunshine-esm	787.93kB	-3.22kB (-0.41%) ⬇️

Affected Assets, Files, and Routes:

view changes for bundle: sunshine-esm

Assets Changed:

Asset Name	Size Change	Total Size	Change (%)
assets/Notification-*.js	-1.38kB	358.1kB	-0.38%
assets/apps-*.js	-1.84kB	10.12kB	-15.35%

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 17.85%. Comparing base (0709990) to head (c31f60e).
⚠️ Report is 1 commits behind head on master.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #5101      +/-   ##
==========================================
- Coverage   17.86%   17.85%   -0.01%     
==========================================
  Files         111      111              
  Lines       24005    24005              
  Branches    10619    10619              
==========================================
- Hits         4289     4287       -2     
+ Misses      18169    15502    -2667     
- Partials     1547     4216    +2669     

Flag	Coverage Δ
Archlinux	11.23% <ø> (ø)
FreeBSD-14.3-aarch64	?
FreeBSD-14.3-amd64	13.37% <ø> (+0.01%)	⬆️
Homebrew-ubuntu-22.04	13.58% <ø> (ø)
Linux-AppImage	12.16% <ø> (ø)
Windows-AMD64	14.84% <ø> (ø)
Windows-ARM64	13.23% <ø> (-0.01%)	⬇️
macOS-arm64	19.03% <ø> (ø)
macOS-x86_64	18.37% <ø> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 52 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0709990...c31f60e. Read the comment docs.

[martona]

The Linux failure was caused by setting the project C++ standard globally without also setting the CUDA standard before the sunshine target is created. Since sunshine includes CUDA sources on Linux, CMake tried to configure that target with CUDA C++23, which nvcc does not support.

I fixed that by setting CMAKE_CUDA_STANDARD to 17 at the top level before target creation, then removed the later CUDA standard setup from cmake/targets/common.cmake. Linux CUDA now builds locally.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[ReenigneArcher]

It's either a coincidence or this PR caused #5112

Do you have some idea why? It's not obvious to me looking at the changes here.

[martona]

I doubt it, the icu4c change was local to macOS, and the C++ standard setting should not cause DLL linkage errors. I'm looking though, stay tuned.

[ReenigneArcher]

This was the only change though, unless the bug is in icu itself, which I didn't see any recent changes in.

[martona]

My windows build box is slow as hell and churning through git checkout recursive right now - i'll know more in maybe half an hour, but my working theory is that none of the mingw toolchain is pinned; something updated and caused a new icu dependency. Plausible?

[ReenigneArcher]

Seems a bit odd as the last update was 2 weeks ago. https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-icu and all that changed was the pkgrel version.

[martona]

The more likely path is Boost. MSYS2 currently installs Boost 1.91, but Sunshine asks CMake for exactly Boost 1.89, so the system package is rejected and we fall back to FetchContent. After #5101, CMAKE_CXX_STANDARD=23 is set globally before dependencies are added, so fetched CMake projects see that setting too. That was intentional, but it means the fetched Boost build environment changed.

I do not yet know that C++23 specifically toggled the ICU dependency, but it's looking more likely with FetchContent being in play.

[martona]

The good news is that Windows builds and runs cleanly with:

cmake -B build -G Ninja -S . -DBOOST_LOCALE_ENABLE_ICU=OFF ...

I also checked the codebase for actual Boost.Locale usage. The only real call site I found is Linux-only:

src/platform/linux/input/inputtino_keyboard.cpp

auto utf8_str = boost::locale::conv::to_utf<wchar_t>(utf8, utf8 + size, "UTF-8");
auto utf32_str = boost::locale::conv::utf_to_utf<char32_t>(utf8_str);

So Windows does not appear to need Boost.Locale’s ICU backend. macOS may be similar, but I’d keep the first fix scoped to Windows unless you’d prefer a broader cleanup.

Would you like me to work on a PR? I should be able to get it done today.

Edit: Nevermind, I see you beat me to it.