[CMake] New compoments MbedTLS and wolfSSL

[Spixmaster]

New CMake component MbedTLS. Fixes #2345.

A decision I needed to make. Use OpenSSL primarily and MbedTLS secondly. As OpenSSL is activated if available, this means that MbedTLS needs to be deactivated even if available.

I tested all four cases HTTPLIB_USE_OPENSSL_IF_AVAILABLE with HTTPLIB_USE_MBEDTLS_IF_AVAILABLE (ON or OFF) .

Also, four cases of HTTPLIB_REQUIRE_OPENSSL with HTTPLIB_REQUIRE_MBEDTLS (ON or OFF).

Each with HTTPLIB_COMPILE=ON.

I have a question regarding CMake. Is the exported target even compatible with ceratainly compiled targets?

Consider build

cmake -DHTTPLIB_COMPILE=ON -DHTTPLIB_REQUIRE_OPENSSL=ON -DHTTPLIB_REQUIRE_MBEDTLS=OFF ..

and usage

find_package(httplib COMPONENTS MbedTLS)

.

What would happen?

Moreover, this was quiet tedious. I want a pay rise.

[Spixmaster]

I researched regarding my question. check_required_components() checks whether the components are found targets in the exported target.

This should be the behaviour if I understood correctly.

Therefore, this pull request should be completely valid.

I am not best friends with CMake. I do not like all the silent error and failures. Moreover, there are multiple ways to do the same thing.

[sum01]

Yes, check_required_components is kind of hacky.

... checks whether all requested, non-optional components have been found, and if this is not the case, it sets the Foo_FOUND variable to FALSE so that the package is considered to be not found. It does that by testing the Foo_<Component>_FOUND variables for all requested required components.

Just a random thought, but CMakeDependentOption could probably be used to clean up all this option-handling code. Not very important, but it's somewhat convenient.

---

The cmake seems fine, although I'm wondering if more of its targets need to be consumed, such as MbedTLS::mbedx509 given this seems to be using it:

cpp-httplib/httplib.h

Line 398 in 14e37bd

#include <mbedtls/x509_crt.h>

There's also that crypto lib MbedTLS::tfpsacrypto too that seems unrelated, but I know nothing about MbedTLS so ignore me if wrong.

---

If I expected all this extra stuff to be added in the future maybe I would've put everything through a macro/function from the start to de-dupe all this work though.

Looking back, I also don't think the various HTTPLIB_USE_XXX_IF_AVAILABLE were a good idea. It just complicates things for a mildly easier end-user build, which isn't always a good thing (re: the past issues about builds "missing" OPENSSL).

[Spixmaster]

So, I am done with the testing of your thoughts. I reverting the test commit. 8682189 was correct and HEAD has the same content.

I also find the options HTTPLIB_USE_XXX_IF_AVAILABLE a bad choice. I do not like non-deterministic behaviour.

cmake_dependent_option()

cmake_dependent_option() is completely useless here and even gives false impression of compatibility checks. The function basically just defines default values and toggles visibility in the GUI, https://cmake.org/cmake/help/latest/module/CMakeDependentOption.html.

It does not prevent from configuring incompatible settings. I tested it. You can set HTTPLIB_REQUIRE_OPENSSL=ON and HTTPLIB_REQUIRE_MBEDTLS=ON without the condition check with message(FATAL_ERROR) ... obvisously and the target will result in compilation errors due to redefinitions.

MbedTLS targets

I tested them individually. Only one target at a time. No sets of targets.

MbedTLS::tfpsacrypto bf099f6

That target is not found. I do not know why.

MbedTLS::mbedx509 1d0b91f

This target causes linking errors.

[ 12%] Linking CXX executable argo
/usr/bin/ld: CMakeFiles/argo.dir/src/database/ArticleComment.cpp.o: in function `httplib::detail::SSLSocketStream::is_readable() const':
ArticleComment.cpp:(.text._ZNK7httplib6detail15SSLSocketStream11is_readableEv[_ZNK7httplib6detail15SSLSocketStream11is_readableEv]+0x4b): undefined reference to `mbedtls_ssl_get_bytes_avail'
/usr/bin/ld: CMakeFiles/argo.dir/src/database/ArticleComment.cpp.o: in function `std::_Function_handler<void (), httplib::SSLServer::process_and_close_socket(int)::{lambda()#1}>::_M_invoke(std::_Any_data const&)':
ArticleComment.cpp:(.text._ZNSt17_Function_handlerIFvvEZN7httplib9SSLServer24process_and_close_socketEiEUlvE_E9_M_invokeERKSt9_Any_data[_ZNSt17_Function_handlerIFvvEZN7httplib9SSLServer24process_and_close_socketEiEUlvE_E9_M_invokeERKSt9_Any_data]+0x7f): undefined reference to `mbedtls_ssl_free'
/usr/bin/ld: ArticleComment.cpp:(.text._ZNSt17_Function_handlerIFvvEZN7httplib9SSLServer24process_and_close_socketEiEUlvE_E9_M_invokeERKSt9_Any_data[_ZNSt17_Function_handlerIFvvEZN7httplib9SSLServer24process_and_close_socketEiEUlvE_E9_M_invokeERKSt9_Any_data]+0x1e2): undefined reference to `mbedtls_ssl_close_notify'
/usr/bin/ld: ArticleComment.cpp:(.text._ZNSt17_Function_handlerIFvvEZN7httplib9SSLServer24process_and_close_socketEiEUlvE_E9_M_invokeERKSt9_Any_data[_ZNSt17_Function_handlerIFvvEZN7httplib9SSLServer24process_and_close_socketEiEUlvE_E9_M_invokeERKSt9_Any_data]+0x23f): undefined reference to `mbedtls_ssl_close_notify'
/usr/bin/ld: CMakeFiles/argo.dir/src/database/ArticleComment.cpp.o: in function `std::_Function_handler<void (), httplib::SSLClient::initialize_ssl(httplib::ClientImpl::Socket&, httplib::Error&)::{lambda()#1}>::_M_invoke(std::_Any_data const&)':
ArticleComment.cpp:(.text._ZNSt17_Function_handlerIFvvEZN7httplib9SSLClient14initialize_sslERNS1_10ClientImpl6SocketERNS1_5ErrorEEUlvE_E9_M_invokeERKSt9_Any_data[_ZNSt17_Function_handlerIFvvEZN7httplib9SSLClient14initialize_sslERNS1_10ClientImpl6SocketERNS1_5ErrorEEUlvE_E9_M_invokeERKSt9_Any_data]+0xaa): undefined reference to `mbedtls_ssl_free'

MbedTLS::mbedtls

Works.

Internal dependencies

From the documentation.

Note that `libmbedtls` depends on `libmbedx509` and `libtfpsacrypto`, and `libmbedx509` depends on `libtfpsacrypto`. 

Therefore (pointing to dependency):
libmbedtls -> libtfpsacrypto
libmbedtls -> libmbedx509 -> libtfpsacrypto

[Spixmaster]

@sum01, I had to switch from cpp-httplib-compiled to cpp-httplib due to make being incompatible with modules and available ninja just sucks. The output is terrible and it compiles in parallel by default which I find a terrible decision. It killed my computer by using all RAM.

[crueter]

It killed my computer by using all RAM.

The humble swap partition:

[Spixmaster]

I am done.

Additionally, this fixes #2361 and #2371.

Beforehand, the working of the incompatibilities was tested separately. I did the following testing all with -D HTTPLIB_COMPILE=ON. The libraries were turned on individually. Both -D HTTPLIB_REQUIRE_XXX and HTTPLIB_USE_XXX_IF_AVAILABLE was tested.

Moreover, build and linking with my consuming project was done. However, linking was not tested with HTTPLIB_USE_XXX_IF_AVAILABLE.

OpenSSL wolfSSL MbedTLS compilation linking
1 0 0 works works
0 1 0 cannot test cannot test
0 0 1 works works

Arch Linux does not enable the proper option needed for the package wolfssl. WOLFSSL_OPENSSLALL is off by default. I get a lot of compilation error. Maybe someone else can test.

[Spixmaster]

#2371 should still be open.

@DarthGandalf, can you add support for meson? Merely, for the reason of completeness.

[DarthGandalf]

can you add support for meson?

I have no good way to test wolfssl, as it's not currently packaged in Gentoo

Also for the ebuild I switched back to cmake for now. Meson makes src_test() much simpler, but when the library is installed via meson, it doesn't provide httplibConfig.cmake, which some users of the library expect