[WIP][DO NOT RUN ACTIONS] Replace autobuild with vcpkg and CMake build system modernization

[RyeMutt]

Description

This set of changes is to modernize the developer experience with vcpkg based dependency management and a cleaned up cmake build system.

The GHA build workflows for this branch are still WIP and should be considered unsafe for use without validation in a private repository.

Branch history currently unstable until Draft status is lifted.

Related Issues

Issue Link: #4390 #4508

---

Checklist

Please ensure the following before requesting review:

• I have provided a clear title and detailed description for this pull request.
• If useful, I have included media such as screenshots and video to show off my changes.
• The PR is linked to a relevant issue with sufficient context.
• I have tested the changes locally and verified they work as intended.
• All new and existing tests pass.
• Code follows the project's style guidelines.
• Documentation has been updated if needed.
• Any dependent changes have been merged and published in downstream modules
• I have reviewed the contributing guidelines.

---

Additional Notes

[Ansariel]

Is there a reason why it is not possible to do a SINGLE thing at a time per PR and NOT mix it with a bunch of other changes so we don't end up in unnecessary giant PRs?

[Geenz]

Hey @Ansariel - I know how disruptive and annoying big changes like these are, however from the LL end there was the decision to group this into a bigger package for the work we commissioned Rye to do here.

That being said, it's my hope that we won't do this again. Large chunks like this is disruptive to everyone, even our engineers. So in the future I'll endeavor to ensure that our statements of work are sufficiently broken up and measurable from the start rather than what this started out as.

[ChorazinAllen]

Hi @Geenz

I believe that this and other changes already in the pipe are going to prove to be the breaking point for all but the best resourced TPVs. Let's look at what's coming down:-

• Removing autobuild will force TPVs to rework their build systems and, probably, do significant work to get their own Linux builds working again unless they pause their Linux releases until the LL one sees light of day
• There's a growing assumption that the only way the viewer is ever built is using GHA. That simply isn't so.
• The change in Windows packaging will again force TPVs to adapt it to their own requirements and package content
• The 2D UI will force TPVs to rework their own UI elements to match the 2D style to avoid a mix of 2D and 3D UI appearing

and that's on top of the routine work caused by LL breaking TPV changes that they're unaware of when something gets refactored.

The biggest elephant in the room though is RLVa. If that ever starts appearing in the LL viewer it's going to cause major issues for every viewer that already has RLV or RLVa included. These TPVs currently have a functional RLV or RLVa and wouldn't cut across to including a LL version until its functionality meets or exceeds what they already have. Assuming the LL development is done in phases, as was previously discussed, it's going to be a merge nightmare to keep LL RLVa elements out of TPVs until it's ready for a wholesale switch over.

This is a lot of disruption for minimal functional change or feature benefit in the viewer and it's putting TPVs with small or single person teams under huge strain for very little gain. I'm pretty sure many other TPVs are feeling the same.

--Chorazin

[Hecklezz]

• Removing autobuild will force TPVs to rework their build systems and, probably, do significant work to get their own Linux builds working again unless they pause their Linux releases until the LL one sees light of day

The vcpkg changes won't be out until after the Linux changes, which will come with the SLua viewer, so at least that worry of yours can be crossed-off. It will still be a lot of work of course to merge everything, but official Linux support in my opinion is extremely important and worth it.

• There's a growing assumption that the only way the viewer is ever built is using GHA. That simply isn't so.

I don't believe this to be the case at all. I have already tested building with these vcpkg changes on my local machine and it is as simple as 1 single command without any other setup, or build environment variables, or any nonsense to create the project (I tested both MSVC and with Ninja). I don't see anywhere that there is an assumption that the only way people do it is with GHA.

• The 2D UI will force TPVs to rework their own UI elements to match the 2D style to avoid a mix of 2D and 3D UI appearing

For the TPVs that mostly follow LL's skin I can definitely see this being a pain and not something fun to do. At least in Firestorm's case, we will likely be throwing out all of the flat UI changes because it is a gigantic merge conflict that will break way too much of our own UI changes that are in place (plans may change of course).

---

Autobuild has been a maintenance burden for LL (they have said as much), and with Signal leaving I imagine even more of a burden now. It is more limiting and harder to work with compared to modern, widely used systems such as vcpkg. So getting it done now and getting through the struggles to move to an industry standard system that LL doesn't need to maintain, is better for everyone.

[DarlCat]

The change in Windows packaging will again force TPVs to adapt it to their own requirements and package content

I took a look again at #5178 and still don't see how the existing Windows packaging code is removed from the viewer with the new one-click project. TPVs already customize their installers, and I don't think many if any will choose to adopt this new approach as-is. Like the flat UI changes already addressed above me the installer will probably also just be dropped on merge by TPVs because there is no obligation to follow the lab's direction on it or really any of the things that were listed.

Third-party viewers exist that are one-person operations, and can't even merge modern Linden code due to license conflicts or in some cases nearing two decades of source code drift; they've objectively been doing fine.

Lastly, being nitpicky here, but with a PR prefixed "WIP do not run actions" how does one arrive at this conclusion when there aren't even finished GHA scripts to build it yet?

There's a growing assumption that the only way the viewer is ever built is using GHA. That simply isn't so.

---

All this to say; I have actually played with these the changes in this PR and I find it MASSIVELY simplifies the development process. Between the whole thing being literally one command to get started, and having cmake integrations working in code editors without any fiddling to take advantage of them, this PR turns what has always been an esoteric and tribal knowledge laden nightmare into a modern batteries-included developer experience.