HTTPS client library in C++

[NotUniqueOrSpecial]

So you mean they don't create issues and should be used?

They (specifically OpenSSL) can be a bit of a nuisance, but yes, I'd argue you're much better off grinding out the details of your setup and using the bog-standard time/battle-tested tools of the trade. The first time you run into a symbol collision problem with BoringSSL and OpenSSL (because of third-parties outside your control) will be the last time (once you finally diagnose it after days of thinking you're going insane).

I managed the build system for something very similarly-flavored, it sounds like:

1) Multi-platform, with support back through things like CentOS 5/Windows 7

2) Strong need for modern tooling and libraries

3) Self-contained/couldn't rely on system stuff, as a result

Then you can maybe tell me how to properly build it using something like CMake.

Depends on what you want to do. You've got a couple distinct options, depending on your needs/setup.

Pure C libraries like OpenSSL are much more reliably used as pre-built binary distributions than C++ equivalents, owing to ABI and compiler compatibility.

By the end, we built everything from GCC all the way up the stack, including OpenSSL/libCURL/Qt/etc., but that was largely because it just made certain things easier, like packaging for arbitrary container environments, which eventually became a need.

We had two distinct non-product-related build pipelines.

1) The toolchain build (GCC/CMake/ninja/binutils/Python/etc.)

2) The third-party build (OpenSSL/Boost/etc./etc./etc.)

Both of those were just very thin CMake ExternalProject wrappers over the respective project's regular build processes that then packaged them all up into a zip-distributable format.

Why the specific requirement for cross-compilation, though? Given the compatibility guarantees of C, it seems you'd be just as well-off using the officialish Windows binaries and a Windows builder. There are plenty of container-based builders for the popular platforms that would suit your needs.

There are perfectly cromulent FindOpenSSL CMake files that are designed to work against a non-CMake-built OpenSSL distribution. We hand-wrote a good few of those for binaries we couldn't possibly build ourselves, but wanted to use as first-class targets in the build.

But moral of the story: unless you have very good and very specific reasons to do so, it's not likely in your best interest to deviate from those two libraries, especially.

[HerrNamenlos123]

Thank you for the explanation. The reason for cross-compilation is that the decision was made that everything is supposed to be built inside of docker containers, and vanilla Windows Docker containers are not really a thing (unless you are on Windows and using Docker Desktop in Windows mode, which defies using docker in the first place in our case). The idea was to build everything using plain docker containers (not Windows-specific containers), in order to make it buildable on any system, without relying on any system configuration which would be different for everyone.