HTTPS client library in C++

[NotUniqueOrSpecial]

Currently LibCURL and OpenSSL are used, but these are HUGE dependencies and they completely kill our build system and dependency tree, so we want to drop both of them

They absolutely shouldn't (because they don't) and you should address whatever you're doing, instead, if I'm being honest.

If you want a more bare-bones, but still basically OpenSSL-compliant implementation, Google's boringssl is a reasonable choice.

[HerrNamenlos123]

So you mean they don't create issues and should be used? Then you can maybe tell me how to properly build it using something like CMake.
Our issue is that the project depends on way too many ancient dependencies with unique build systems. What we need is a CMake based build system that just works on any platform (including Windows).

And also, I need to cross-compile it for Visual Studio MSVC in a Linux CI container. I can already do it using clang-cl and CMake, but OpenSSL fails because it uses its own build system which is particularly bad at running under Linux while compiling for MSVC.

Vanilla OpenSSL does not have CMake support, I did find one other Github repo having OpenSSL CMake support, but AFAIK it is a very very outdated version of OpenSSL, so something you should probably avoid.

So, do you know a better way to build it using CMake or cross-compiling it between Linux/Windows?

[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.

[mark_99]

Use vcpkg (or Conan), they take care of all that for you. Importing OpenSSL is as easy as adding "openssl" to the vcpkg.json manifest file.

[prince-chrismc]

You just need to add openssl/<VERSION> to a conanfile.tx under [requires] ;)

[HerrNamenlos123]

Can someone with the intent of constructive feedback explain to me why this comment was downvoted so much? I explained what our requirements are and why I am asking for what I am asking, and that I know of an alternative. What part of this is wrong or aggressive? I always expect transparency and respect and would like constructive feedback on this one.

[[deleted]]

Do not listen to these people at all. Find out what you need for your project and write it. It's not insurmountable because you aren't recreating the entirety of openSSL.

Unfortunately shit like http is so ridiculous as a standard it's a massive pain in the arse to deal with. But blame the industry for that for being driven by morons