add_android_openssl_libraries: Automatically link OpenSSL on argument…

[aambrosano]

… targets

[aambrosano]

For the record, OpenSSL::OpenSSL is not really the right target. FindOpenSSL will actually create OpenSSL::crypto and OpenSSL::ssl, however linking against those targets is still generating errors at the CMake generation step. Couldn't figure out why yet.

[Issam-b]

keep local variable as lowercase

[Issam-b]

I think this can also be under the ${ARGN} loop

[Issam-b]

we no longer need to assign this android_extra_libs list if we're doing it for OPENSSL_SSL_LIBRARY and OPENSSL_INCLUDE_DIR, we can use those latter two variables directly for QT_ANDROID_EXTRA_LIBS

[Issam-b]

For the record, OpenSSL::OpenSSL is not really the right target. FindOpenSSL will actually create OpenSSL::crypto and OpenSSL::ssl, however linking against those targets is still generating errors at the CMake generation step. Couldn't figure out why yet.

This doesn't work for me, I get an error:

CMake Error at ~/Library/Android/sdk/android_openssl/android_openssl.cmake:24 (target_link_libraries):
Target "tst_openssl" links to:

OpenSSL::OpenSSL

but the target was not found. Possible reasons include:

* There is a typo in the target name.
* A find_package call is missing for an IMPORTED target.
* An ALIAS target is missing.

Call Stack (most recent call first):
CMakeLists.txt:17 (add_android_openssl_libraries)

[Issam-b]

@aambrosano btw the commit message doesn't explain why such patch is needed, is it trying to fix some bug?

[Issam-b]

@aambrosano on this

For the record, OpenSSL::OpenSSL is not really the right target. FindOpenSSL will actually create OpenSSL::crypto and OpenSSL::ssl, however linking against those targets is still generating errors at the CMake generation step. Couldn't figure out why yet.

It doesn't work because the targets should be OpenSSL::Crypto and OpenSSL::SSL not OpenSSL::crypto and OpenSSL::ssl.

[aambrosano]

@Issam-b it just made sense that we linked against OpenSSL in the targets we passed to add_android_openssl_libraries, which we weren't doing. Otherwise we'd need to look up for those libraries twice and that would be redundant. All other changes were just small adjustments.

@aambrosano btw the commit message doesn't explain why such patch is needed, is it trying to fix some bug?

[aambrosano]

@aambrosano on this

For the record, OpenSSL::OpenSSL is not really the right target. FindOpenSSL will actually create OpenSSL::crypto and OpenSSL::ssl, however linking against those targets is still generating errors at the CMake generation step. Couldn't figure out why yet.

It doesn't work because the targets should be OpenSSL::Crypto and OpenSSL::SSL not OpenSSL::crypto and OpenSSL::ssl.

I was just typing targets names off the top of my head when commenting, but was using the right names when coding. That will not work anyway because for some reason targets found within a function are not available outside of the scope of the function. Trying to link against OpenSSL::SSL and OpenSSL::Crypto will result in an error message like this one:

CMake Error in CMakeLists.txt:
  The dependency target "OpenSSL::SSL" of target
  "mytarget_autogen_timestamp_deps" does not exist.

Even when converting the function to a macro (which has its own caveats anyway) the listing will produce the same error. Will have to think about this one a bit more.

[Issam-b]

@aambrosano do you still have the issue above? things work right on my side with this PR, I'd like to check that before submitting this.

[alcroito]

2 comments here

1. GLOBAL option was introduced in cmake 3.24. Any project using a lower cmake version would not be able to use this function anymore. This includes also latest Qt projects, which require a minimum of 3.22.

2. Even if the cmake verison was not an issue, creating global targets is generally not great, because it prevents being able to create local (directory-scoped) targets with the same name, but in different directories.

[Issam-b]

I took the liberty to remove that, in the last commit, @alcroito does the patch look good for you?

[alcroito]

Personally, i don't think it looks good, but i'm not the maintainer.

aambrosano mentioned that without GLOBAL, the targets are not available in certain cases. I believe him. So for some use cases it likely won't work. Probably has to do with the scope where the function is called, and where the app is created.

Furthermore, doing find_package inside functions is frowned upon, because all the variables that find_package sets won't be available outside.

Also, I find it strange to do find_package(OpenSSL) to create the targets with pre-filled input from the computed variables.

At that point you could just create the imported targets manually, and avoid the find_package call altogether.

[Issam-b]

I pushed a new version that avoids the issues pointed out by @alcroito. This is working correctly for me, @aambrosano does it work in the cases that were problematic for you before?