libcurl: expose CMAKE_OPENSSL_AUTO_LOAD_CONFIG

[rzvncj]

This does for cmake builds what --enable-openssl-auto-load-config
does for autoconf builds.

[rzvncj]

Do I need to do something about the one failing check? Is it a false positive?

[bagder]

No, that's a flaky test causing a false positive. Your PR looks fine!

[rzvncj]

Thanks!

[jzakrzewski]

We have this unfortunate set of options beginning with "CMAKE_". GUI tools use those prefixes to group options together, so it's kinda namespacing which we're hijacking :/. I'd prefer we wouldn't add more of those. Could you come up with a name that does not begin with "CMAKE_"?
Apart from that it looks clean to me.

[rzvncj]

We have this unfortunate set of options beginning with "CMAKE_". GUI tools use those prefixes to group options together, so it's kinda namespacing which we're hijacking :/. I'd prefer we wouldn't add more of those. Could you come up with a name that does not begin with "CMAKE_"?

Sure, I can change it to whatever you find more suitable. I've just been following what appeared to be the current convention. I guess the simplest change would be to simply remove the CMAKE_ prefix - so making this OPENSSL_AUTO_LOAD_CONFIG. If that works for you I'll change it and update the pull request.

[rzvncj]

I've updated the pull request. Please take a look when you've got time and let me know if there's anything else I can do. Thanks!

[rzvncj]

Ping? :)

[jzakrzewski]

Sorry - I'm quite busy those days.
I definately like it better but even then I'm concerned about using other project's name (OPENSSL_) at the beginning of the option name. The bad thing is we seem to use CURL_* variables internally only where it would make much sense to prefix option names with it. I don't really have a good idea at the moment. CURLOPT_* maybe?
I'd love to hear others @jay seems to have a very critical (in a good way) approach to things like that.

In case you were wondering what I mean by grouping, this is what CMake GUI does:

[rzvncj]

Thanks! Yes, I did understand your grouping concern. I'm perfectly happy to name the cmake option to whatever is agreable to the project maintainers.

Looking at the current CMakeLists.txt file I see several patterns emerging:

1. No prefix at all (e.g. ENABLE_DEBUG).
2. A CURL_ prefix (e.g. CURL_DISABLE_FTP).
3. A CMAKE_ prefix (e.g. - and this is why I've prefixed the new option with CMAKE_, since it's CMAKE_USE_OPENSSL-dependent - CMAKE_USE_OPENSSL).

To me, the CMAKE_ prefix looks like the best fit with the "parent" option CMAKE_USE_OPENSSL (grouping notwithstanding), but it really doesn't matter - the priority is just to have this pull request merged.

Unfortunately I don't know what else to suggest naming-wise. I'll wait for @jay's suggestion, as requested.

[rzvncj]

Also, if we don't keep the CMAKE_ prefix, and with the current grouping, and assuming we don't want to break the cmake-based builds of existing curl clients (by renaming CMAKE_USE_OPENSSL as well), we'll have CMAKE_USE_OPENSSL in one group, and whatever else we call the (?)_OPENSSL_AUTO_LOAD_CONFIG option in another group. They feel like they should be in the same group to me.

[jzakrzewski]

Yes, those are exactly the things I've been thinking about and haven't come up with a good answer.

As this is not only strictly CMake question, maybe also @bagder could throw in something. Some general thoughts? What about cleaning this mess up? Would that be considered breaking backwards compatibility?

[jay]

I definately like it better but even then I'm concerned about using other project's name (OPENSSL_) at the beginning of the option name. The bad thing is we seem to use CURL_* variables internally only where it would make much sense to prefix option names with it. I don't really have a good idea at the moment. CURLOPT_* maybe?
I'd love to hear others @jay seems to have a very critical (in a good way) approach to things like that.

I'm sorry to say I don't have a strong opinion about cmake namespacing. If we change the existing option names now we're going to break builds. As I mentioned in a recent PR I thought USE_xxx was for libraries and CURL_xxx was for protocols. If you run cmake -LAH you can see there's a mix in the way configuration options are prefixed, and IMO no clear winner. Here are a few to make the point:

// Use libSSH
CMAKE_USE_LIBSSH:BOOL=OFF

...

// disables HTTP
CURL_DISABLE_HTTP:BOOL=OFF

...

// Set to ON to enable c-ares support
ENABLE_ARES:BOOL=OFF

...

// Use libidn2 for IDN support
USE_LIBIDN2:BOOL=ON

What about CURL_DISABLE_OPENSSL_AUTO_LOAD_CONFIG:BOOL=OFF (which is also the name of the symbol) ?

[rzvncj]

Changed to CURL_DISABLE_OPENSSL_AUTO_LOAD_CONFIG. Please let me know if there's anything else you'd like addressed. Thanks!

[jzakrzewski]

Thanks, @jay this is the voice I wanted to hear.
@rzvncj thanks for your patience.

[rzvncj]

No problem, all's well that ends well. 👍

[jay]

Thanks