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

Open
  • Is something wrong?
#280 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
25/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
cmake, cpp
Domain
build-system, devtools

Research direction

This issue is a roundup across submodules, and most listed fixes already have open pull requests. Start by checking the linked PRs for status and overlap; the two unclaimed changes name scene_rdl2/lib/render/util/IndexableArray.h and arras/distributed/CMakeLists.txt. The work is done when maintainers choose which outstanding portability fixes to take forward and redundant proposals are resolved.

Written by the indexing model from the issue text.

Description

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 #1/#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.

Dominant language
CMake
Stars
4.7k
Forks
321
Avg merge
13m
Merged PRs (30d)
3

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from OpenMoonRay/openmoonray

All issues in OpenMoonRay/openmoonray

Similar issues

More Build System issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.