Several build-portability fixes already have open PRs across submodules — a roundup

[gonsolo]

Context

While updating the Arch Linux openmoonray AUR package to v2026.29.1, I've been maintaining a local patch to build cleanly on a modern toolchain (GCC 16, Boost 1.92, TBB 2023+, CMake 4, and a monolithic USD package). Cross-checking that patch against open PRs across the org, most of it turns out to already be proposed upstream — just sitting unreviewed, some for months. Listing them here in case it's useful to have them in one place.

I also checked each of these against the Rocky 9 build (GCC ~11, Boost 1.75, classic TBB 2020.3, non-monolithic USD, per building/Rocky9/install_packages.sh): none of them regress that build. The version/include fixes are backward-compatible no-ops there, and the two USD/TBB CMake changes are guarded (if(TARGET usd_ms), find_package(TBB CONFIG) falling through when not found) so they simply don't trigger on that toolchain.

Ready to merge (single PR each, exact fix)

• arras_render #2 — missing <functional> include in OrbitCam.h
• cmake_modules #2 — prefer modern system-provided TBB via find_package(TBB CONFIG) before falling back to the bundled find-module
• hdMoonray #5 — support monolithic USD builds (interface polyfills for a combined usd_ms target)
• moonray_sdr_plugins #1 — same monolithic-USD fix
• moonshine_usd #1 — same monolithic-USD fix
• moonray #12 — disable AVX512PF/AVX512ER cpuid checks removed from newer compiler headers
• moonray_gui #3 — standardize on Q_EMIT/Q_SIGNALS/Q_SLOTS to avoid the Qt/TBB keyword collision (covers 7 files, supersedes older Welcome to MoonRay! #1/Moonray for windows ? #2)
• moonshine #8 — DwaBase attribute lookup fix for stricter C++ standards

Same fix, multiple competing open PRs (worth picking one and closing the rest)

• mcrt_dataio: #6, #7, #9 all add the same missing <cstdint> include in ClockDelta.h
• scene_rdl2: #11 (narrow) and #13 (broader, also covers BinPacketDictionary.h and the python CMake Boost::system removal) overlap

Already merged

• arras4_core #8 — Boost io_service→io_context, drop Boost::system 🎉

No PR yet, if anyone wants to pick these up

• scene_rdl2/lib/render/util/IndexableArray.h — typename hasher::result_type → std::size_t (the former isn't guaranteed by std::hash in a way that compiles cleanly everywhere)
• top-level arras/distributed/CMakeLists.txt — drop system from its Boost find_package COMPONENTS list (same class of fix as the merged arras4_core one)

Happy to help review/rebase any of the above if that's useful — just flagging since they'd remove a good chunk of what downstream packagers currently have to patch around.

[gonsolo]

Care to merge one of the easier ones above, @jlanz @randypacker?

[jlanz]

Hi @gonsolo,

Thanks for collecting all of these together. I'm currently focused on trying to get an initial CI in place in the OpenMoonRay/openmoonray repo, and once that is done I plan to do a full sweep of all active PRs and finally get them merged. We have not been nearly as responsive in reviewing and merging PRs as we'd like to be, but we are actively working to change that.

I'm sure many of the PRs listed here are probably "safe" to merge, but I'd prefer to wait until we have our CI in place. We're actively working with the ASWF CI working group to get the images built and hope to have it up and running soon. Thanks for you patience!

[gonsolo]

Hi @jlanz,

I'm glad to see these patches merged some day. Every few months I upgrade my Arch Linux OpenMoonRay package and have a look what has changed. Don't misconceive my messages for impatience, I'm happy to wait. 😄

(I was in the room at the Moonray meeting at SIGGRAPH this year, just to shy to say hello, maybe next year. 😄 )