configure: make the TLS library choice(s) explicit

[bagder]

With this, configure no longer tries to find a TLS library by default, but all libraries are now equal: the user needs to explicitly ask what TLS library or libraries to use.

If no TLS library is selected, configure will error out unless --without-ssl is explicitly used to request a build without TLS (as that is rare these days).

Update: this also removes --with-winssl and --with-darwinssl as they've been deprecated since 2019

[jay]

why? this will break some builds and seems unnecessary

[bagder]

Any kind of auto-detection have to use an order of detecting the libraries that makes us have to choose that order of preference. This way, we remove ourselves from making that decision. Without a change like this, we implicitly say that OpenSSL is to prefer, while I'm not sure that's a good leg to lean on forever.

(I also wanted to remove the need for --without-ssl or --without-openssl when selecting another TLS backend, but I will agree that it can be done without forcing the user to make this selection.)

[bagder]

@mback2k it'd be great if you could update your buildbots' configure invokes to use --with-schannel instead of the deprecated --with-winssl - so that we can make sure things build fine there as well with this change.

[bagder]

This change highlights an existing problem we didn't notice before: the three azure pipelines builds msys1_*debug_openssl all fail to detect OpenSSL in configure and therefore builds and continues with TLS disabled. Contrary to expectations.

With this change, those configure runs instead return failure. Ie the problem exists since before this change, but now we see it better.

@mback2k do you know what we can do to make openssl detected and used in those builds?

[bagder]

The appveyor builds similarly build without TLS enabled (== fail to detect any). I'll try to enable schannel for those.

[mback2k]

@mback2k it'd be great if you could update your buildbots' configure invokes to use --with-schannel instead of the deprecated --with-winssl - so that we can make sure things build fine there as well with this change.

Done since yesterday evening.

@mback2k do you know what we can do to make openssl detected and used in those builds?

No idea yet, but I will look into this over the weekend.

[mback2k]

After checking the available packages for classic MinGW, I think there is no native OpenSSL package available. Just the msys1-environment specific msys-openssl package that won't work for native Windows builds and is most likely already present in the build environment due to being a dependency of other packages. So I guess we have 2 options now:

1. remove the 3 superfluous builds as suggested in this PR
2. turn them into builds without SSL since I guess we don't have any such builds on native Windows yet

[mback2k]

While option 2 basically restores the previous CI situation. Another option could be to build OpenSSL for these CI variants, but I don't think it's worth the effort.

[bagder]

ok, let's switch off TLS in those builds for now

[dscho]

why? this will break some builds and seems unnecessary

It's actually a bit worse: it does not break builds. At least here, I was building Git for Windows' cURL package using --with-winssl and it did not fail to build. What it failed was to tell me that I should fix by build script already ;-)

[bagder]

Oh, you mean when you actually wanted schannel and OpenSSL ... I didn't think about case that's true! 😞

[dscho]

Oh, you mean when you actually wanted schannel and OpenSSL ... I didn't think about case that's true! 😞

Not a big deal, but do you think there might be a way to error out upon unhandled --with-<something> options?

[MarcelRaad]

It was similar for me: I had --without-ssl --win-winssl, which previously enabled schannel and now builds without SSL quietly.

[stanhu]

#7994 should fix the handling of --without-* flags.