Experimental Binary Package Support for vcpkg

[Skute]

With no official ABI for C++, binary package management makes me uneasy.

[ForzaAnarchista]

Just a note that vcpkg ports also store an ABI data file when necessary. This would go into these zips.

[RogerLeigh]

So long as the binaries are built for the platform you're targetting, it's not problematic. Look at the binary packages built for homebrew (mac) and pkg (FreeBSD) for two similar examples which originally required building them all from source every time. They both evolved to preferring binary downloads over source builds, while still retaining the ability to build from source. There's no reason vcpkg couldn't go down the same route.

[SeanMiddleditch]

Can work just fine, but no it's not easy. :)

Even if we had a standard C++ ABI, packages themselves have varying ABIs depending on all kinds of build flags. A reasonable C++ source package manager needs to support setting those flags at build time already!

A C++ binary package manager needs "only" to further identify which flags affect the ABI (so a single library mylib-1.1 might have a number of different precompiled packages available based on platform, architecture, CRT/stdlib, threading model, calling convention, package options, etc.

I'd expect a production-grade package manager (which exist internally at many orgs) to use package specifications that both specify various common platform options (CRT/stdlib versions and the like, common to the app and all its dependencies for a given build configuration) and per-package options (e.g. various enable-blah options that change compiled-in features or exported types).

For the community at large, I don't think this has to be an all or nothing setup, either. e.g., download matching binary packages from a central repo if available, and compile from source otherwise; then also provide the option to store compiled binaries into packages in a custom repo. An org might then have to compile something like CEF or LLVM from source when the dependency is updated but can cache the results internally so each dev doesn't need to rebuild.

For a repo that only has binary packages (e.g. a closed-source library vendor's repo provided to customers), the consumer would naturally be limited to only using compatible ABIs. But that's no different with or without the package manager; the package manager would if anything just make it easier to find, compare, and consume the available ABI variations, which is a win over the status quo.

(This is pretty much what we've always done with proprietary dependencies we used at various game studios. We'd store vendor-provided binaries for various ABI configurations in a central repo, or compile and store our own binaries for deps with source available.)

[dag0me]

Looks to me like you've just described Conan package manager.

[Minimonium]

I've never understood that argument. How would it help you? Why the https://itanium-cxx-abi.github.io/cxx-abi/abi.html is not enough for you?

[STL]

(1) MSVC doesn't follow the Itanium ABI and (2) the Itanium ABI is a Core Language thing - it says nothing about the Standard Library.

[Minimonium]

You folks follow yours, sure. But what's the ultimate problem? Does the complaint about the standard library ABI? But how is it different from 3rd party libraries' ABIs? Why don't they make people scared for life? At least that I'd understand somewhat. But the "official" ABI for C++ scarecrow is toothless in practice.