Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vcpkg seriously borks #30

Open
marceline-cramer opened this issue Jul 15, 2021 · 0 comments · May be fixed by #31
Open

vcpkg seriously borks #30

marceline-cramer opened this issue Jul 15, 2021 · 0 comments · May be fixed by #31

Comments

@marceline-cramer
Copy link
Contributor

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?

@marceline-cramer marceline-cramer linked a pull request Jul 15, 2021 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant