[WIP] 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.

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.

[ChorazinAllen]

Thanks @Hecklezz and @DarlCat for the comments.

I do support the intent of this project, respect the amount of work that's gone into it and will be glad to move away from autobuild too. What troubles me though is the size of this PR and the number of merge conflicts it's likely to throw up when it first meets a TPV codebase.

Knowing that this will surface after Linux does indeed make that side of things much easier.

Windows packaging: I'm tempted to just exclude that too since TPVs (except Firestorm) are generally not what a new user will start out with, however it's usually the case that when old and new methods exist in parallel sooner or later there's a position where only the new is maintained and the old falls behind and eventually stops working until it's finally removed from the code base as a mercy killing. Avoiding that in a TPV keeping NSIS means an overhead of keeping an eye on changes to the new to see whether they need to be ported back to the old and dodging the bullet when old is eventually removed from upstream.

2D UI: I'm also tempted to exclude that too, however again it's not that simple. If a TPV chooses to remain 3D there's then another new maintenance overhead to identify assets created for future new features in the 2D UI style and make 3D versions. These would typically slip through in a merge (new item, so there's no merge conflict) and have to be checked for specifically whilst sorting out the merge conflicts.

--Chorazin

[Hecklezz]

For any TPV devs who haven't ventured into merging this yet, as long as you have already merged in linux-develop, it honestly isn't that bad and the conflicts were fairly straightforward. I got this merged and all working in our internal firestorm development build for both Windows and Linux (awaiting Rye to finish Mac stuff before testing that), and everything is working and packaged almost identically how it was with autobuild. There was a few things here and there after the fact you notice and need to fix or were slightly wrong despite the viewer working, or doing a few little changes to fix debug builds, but they were all fairly easy to spot and fix.

Working with vcpkg is honestly pretty nice, and although I've always used my own python helper script to avoid the annoyances of autobuild and the initial setup of it, for those who are cloning and building the viewer from scratch or don't have a helper script, they will have a far easier time and it will feel more intuitive.

The only real downside of the vcpkg setup as it is right now, is if the packages aren't built and cached yet, it can take ~30+ minutes for it to do so on initial configuration before you even get to building the viewer. Ideally you only ever have to do this once (or at least rarely), so it shouldn't be an issue, but it will be one of the main differences people will notice.