Skip to content

Consider de-vendoring libraries available via vcpkg #4275

Description

@johnnovak

The vendored libraries in src/libs exist because most of those libs are rather niche, so no system deps or Meson ports exist for them. Vendoring them was the easiest and most practical thing to do when they were introduced (and I did introduce a few myself).

Once we're on CMake + vcpkg, the new policy is very simple: only vendor something if it's not available through vcpkg. Moreover, we should gradually de-vendor what we can and make use of the available vcpkg packages instead.

An exception to this rule would be if the library pulls in half the world on Windows, e.g., anything that relies on glib, iconv, etc.

I quickly went through src/libs and this is my assessment. The following could be de-vendored as they are available via vcpkg:

  • ghc (but could be replaced by std::filesystem which would be better)
  • enet
  • loguru (if we haven't done any custom hacks)

These must stay vendored as they're very niche and don't have vcpkg packages:

  • clap (headers only)
  • ESFMu (not commonly available)
  • manymouse (not commonly available)
  • mverb (not commonly available; slightly modified & cleaned up)
  • nuked (not commonly available)
  • residfp (not commonly available)
  • tal-chorus (ripped out from a larger project)
  • PDCurses (we use @kklobe 's custom hacked version that has SDL2 integration added)
  • whereami (not commonly available)
  • simde (not commonly available; header only)
  • YM7128B_emu (not commonly available)
  • zmbv (not commonly available)

The audio decoders stuff is a special case:

  • decoders/xxhash (not commonly available; header-only)
  • decoders/stb_ (not commonly available / header-only; we should consider replacing them with better common libraries, eventually)
  • decoders/dr_ (not commonly available / header-only; we should consider replacing them with better common libraries, eventually)

These interface with our patched version of SDL_sound, so we'll keep them for now, but ultimately it would be preferable to get rid of SDL_sound altogether and use the decoders directly via our own abstraction layer.

Metadata

Metadata

Assignees

No one assigned

    Labels

    build systemBuild system related issues

    Fields

    No fields configured for Feature.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions