viewer.git/indra/llprimitive/CMakeLists.txt, branch 26.4

Merge remote-tracking branch 'secondlife/release/26.4' into 26.4

2026-09-04T13:58:53Z

Merge branch 'main' into 2025.08

2025-11-07T07:08:12Z

Update the upstream ColladaDOM revision used to 10

2025-11-07T06:54:52Z

As the maintenance using an external patch is getting harder, I had to revert the patching to internal and the building to be in the configuration phase, made worse by CMake 4 on Arch, Gentoo and Tumbleweed that treats the absence of a minimum requirement as an error (the BSD sed condition is put there as an anticipation for when in the future (Mac)Ports' CMake gets updated to 4 too).

Introduce global precompiled header to accelerate build

2025-10-27T08:59:15Z

Signed-off-by: Rye

Merge tag 'Second_Life_Release#4e2a9667-2025.08' into 2025.08

2025-10-26T04:45:19Z

Merge tag 'Second_Life_Release#01823996-2025.08' into 2025.08

2025-10-25T12:03:33Z

Rework new convex decomp into a physicsextensions stub package and fix havok and havok_tpv builds for darwin universal to utilize new vhacd stub (#4858)

2025-10-20T17:10:19Z

Initial VHACD based llconvexdecomposition

2025-10-03T13:51:03Z

Merge branch 'main' into 2025.05

2025-07-18T05:58:14Z

Get the viewer installable on Debian arm64

2025-07-07T14:32:30Z

The Debian version supported is 13 (trixie), because that's the version I could install on my M1, hence the Boost default version is 1.83 & we can use system's OpenJPEG 2.5.3. Somehow CMake's FindOpenGL wasn't effective, but we can get around this by setting the GL libraries paths when running cmake. Debian aarch64 suffers from the same problem Fedora aarch64 had when compiling libcurl, and it's assumed that it's Linux aarch64 thing. When trying to build ColladaDOM when building the viewer, it couldn't find Boost somehow, so building ColladaDOM is done in configuration stage instead. Upstream Variables.cmake is full of assumptions regarding architecture, and ARCH is used in many places already for Debian/Ubuntu, so we have to make sure ARCH is set with the correct value at the root level. Pipewire on trixie is also too new, so it's cancelled here. Some dependencies have the t64 suffixes on them, just like the currently supported Ubuntu (because I guess 24.04 *is*, based on trixie). The executable still crashes when launched on my M1, however, but we'll commit the progress so far for now.