vcpkg seriously borks #30
Description
Is there any reason to keep it? Seriously, there has to be a good reason.
Pros of vcpkg:
- easy continuous integration dependency setup
- one-click dependency setup... on Linux only
Cons of vcpkg:
- astronomical setup times (has to download, configure, and compile dozens of dependencies, including, god forbid, LLVM)
- massive footprints on disk (one gigabyte for the build directory in the prototype engine, plus hidden binary caching)
- doesn't even work on Windows (requires manual linking, and Windows CI breaks)
- complex build system implementation (nobody knows how anything works except Tim and me)
This fucking sucks!
How about instead, we do CMake dependency wrangling through simple find_package calls... nothing too fancy, dependencies can be handled per-operating system as appropriate, and users of those operating systems are made responsible for setting up their own development environment, instead of having the build system actively making all of that harder.
Linux package repositories, even the most minimal ones like Debian, have all the basic dependencies (SDL, OpenXR, Vulkan, libuv, etc.), and anything else that isn't in the package repos we can drop in either in-tree as source (FLECS, Tracy), in-tree as compiled binaries (Wasmtime), or as a submodule as a last resort. Dependencies on Windows can be managed with the already existing package managers like Chocolatey. There is absolutely zero need for any extra complexity.
We can always modify/upgrade this later, if the need makes itself apparent. Anything past that is unnecessary complexity and stress.
Thoughts?