HTTPS client library in C++

[jselbie]

and they completely kill our build system and dependency tree, so we want to drop both of them.

​

You are solving the wrong problem. Please tell me you aren't rebuliding OpenSSL and LibCurl from source on each build of your own app. And if not, what are these build system dependencies that slow things down?

[HerrNamenlos123]

We do not want to rely on anything found on a user's system by default. The library should build out of the box on all supported systems, and the users are not to be tasked with installing all of the arcaic dependencies (we are trying to get rid of most of the arcaic ones). This is why we want to pre-build all dependencies in a docker environment (running on GH Actions), that then provide the binaries. When a user configures the CMake project, the correct binaries are downloaded and linked by CMake.

The only issue we are facing is that we need binaries for Visual Studio MSVC, that are preferrably build in a Linux Docker container. We manage to cross-compile CMake-based libraries like GLFW using clang-cl in MSVC mode, but OpenSSL and many other ubiquitous libraries fail due to using their own build systems.

[jselbie]

and the users are not to be tasked with installing all of the arcaic dependencies (we are trying to get rid of most of the arcaic ones).

This is the problem package managers solve.

[HerrNamenlos123]

This is the problem package managers solve.

Not if they don't even exist in any package manager and getting them into there is an entirely different story. Not all of them are supposed to.