Note, the include_directories is also implied when linking the target, so this isn't needed any more.

I am not certain if these targets are safe to use without checking if the component is found. Do your tests cover if ssl or crypto is missing or does anyone know? Otherwise we should research it before accepting this.

This should fail to build and CMake should complain about the imported targets missing if OpenSSL is not found.
But the problem is that we require CMake 2.8.12 and the OpenSSL module gained imported targets in 3.4, so we cannot use them unless we're willing to copy newer version of the FindOpenSSL.cmake to the curl repository.

Ok, then I think the concern I raised is resolved. There's just the matter of cmake version now.

Well, this is your call. Personally I don't think you're gaining that much compatibility sticking with very old versions of cmake. Even if someone is on an old linux distribution, it's trivial to update the cmake version. But it sounds like you can just copy the find module, from a modern version, and not even have to update the version, so that sounds like a good compromise to me.

@johnb003 Could you please update PR with cmake_minimum_required(VERSION 3.4... as well?

@bradking This sounds like an interesting problem for CMake in general.

My take is, if you're expecting to be this regimented about versions, you should be describing the known compatible version range of the library you're working with in the first place (as @jzakrzewski suggests), but practically this doesn't happen that often, and besides most of the established libraries won't be making big breaking API changes.

So the situations are:
You build curl expecting X and end up linking in the app with Y.

By the way, with DLLs this is kind of intended behavior. The question is the compatibility between X and Y, and is there any really standard way to determine this?

if Y < X, that can be be bad, but it can also work if it's the same major version and there's no breaking API changes.

if Y > X, this is probably quite common, as you can update the system dlls and not rebuild everything that depends on them, again it has to be within API compatibility though.

I guess if the ConfigXXX.cmake is written with a variable, you can inject the value you want during the install with the known minimum major version of the library. I mean, that's what configure_file is for right?

AFAIK find_package (and, by extension, find_dependency) normally does the right thing with versions, so if you write find_package(OpenSSL VERSION 1.0.0) it should find also 1.1.0 for example but not 0.9.8.

The find_dependency must however be told about the expected version. Doing it with the magic of configure_file seems right for me but I don't have enough experience to tell if this is the way to go - I'm maintaining CMake build system in a strictly-controlled environment, so such things do not happen ;)

@jay almost all LTEs provides packages for cmake3. And travis-ci checks are passed.
Of course, we could ask for votes in the mailing list before merging.

@jzakrzewski Not sure if the explicit version should be provided unless automake already enforces specific version. AFAIR, we should mimic autotools build...

@snikulov Well, I think that if curl pulls OpenSSL 0.9.8 and user program pulls OpenSSL 1.0.0 it'll break badly. If you're lucky it will be linker errors. If you're not - random runtime errors and crashes. I had two versions of an LDAP library linked once. It was no fun debugging it. I don't think mimicking autotools in every aspect is right if we can do better.

I matched only the major version, because OpenSSL can use non-standard patch description versioning semantics, like 1.0.2o which will create an error if used as the search version for find_dependency.

find_package called with invalid argument "1.0.2o"

Once content substitution is done then the input file should be renamed with a .in extension so that nothing ever tries to read it as a valid .cmake file.

Done. + rebased since curl-config.cmake also changed upstream from original PR, which resulted in a force push to my branch.

Thanks.

The CURL_FIND_REQUIRED_libcurl value is set only if find_package is called with REQUIRED. Even if it is not a required package we still need to look for curl's dependencies.