Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[question] OpenSSL: casing issues in CMake module #452

Closed
jgsogo opened this issue Dec 10, 2019 · 9 comments
Closed

[question] OpenSSL: casing issues in CMake module #452

jgsogo opened this issue Dec 10, 2019 · 9 comments
Labels
question Further information is requested

Comments

@jgsogo
Copy link
Contributor

jgsogo commented Dec 10, 2019

Hi! I've just realized that the OpenSSL has some casing issues. According to the CMake module:

OpenSSL::SSL
OpenSSL::Crypto

but,

OPENSSL_FOUND
OPENSSL_INCLUDE_DIR
OPENSSL_CRYPTO_LIBRARY
OPENSSL_SSL_LIBRARY
OPENSSL_LIBRARIES
OPENSSL_VERSION

So, not even the cpp_info.names["cmake_***"] or the cpp_info.name will be able to deal with it, right? Am I missing something?

Thanks!

@jgsogo jgsogo added the question Further information is requested label Dec 10, 2019
@madebr
Copy link
Contributor

madebr commented Dec 10, 2019

I asked something similar at conan-io/conan#5717 (comment)

@jgsogo
Copy link
Contributor Author

jgsogo commented Dec 11, 2019

Do you think we should go for the build_modules approach (add it to OpenSSL), or shall I modify the consumer to match the casing (I found this issue package tgbot)?

@SSE4
Copy link
Contributor

SSE4 commented Dec 11, 2019

I don't think it's possible to generate multiple CMake targets without the components feature

@jgsogo
Copy link
Contributor Author

jgsogo commented Dec 11, 2019

Right, my problem is related to the upper/lower case of the variables. tgbot consumes OPENSSL_LIBRARIES, but we have OpenSSL_LIBRARIES.

@SSE4
Copy link
Contributor

SSE4 commented Dec 11, 2019

very inconsistent, as usual, e.g.
https://cmake.org/cmake/help/v3.16/module/FindBZip2.html
vs
https://cmake.org/cmake/help/v3.16/module/FindBoost.html
and the most contradictory:
https://cmake.org/cmake/help/v3.16/module/FindLibXml2.html
notice LibXml2_FOUND vs LIBXML2_INCLUDE_DIR
without very flexible customization in generator, it's hard to satisfy every case
seems like it's very random, there is no logic, no standard, no specification...

@jgsogo
Copy link
Contributor Author

jgsogo commented Dec 11, 2019

Probably we should follow the comment linked by @madebr and we shouldn't try to recreate the CMake mess. It would be better to patch the build scripts of the consumers when there is some inconsistency, don't you think so?

@SSE4
Copy link
Contributor

SSE4 commented Dec 11, 2019

I agree, it's impossible to provide drop-in-replacement for something that is not well-defined, unfortunately.

@madebr
Copy link
Contributor

madebr commented Dec 11, 2019

I've gone the manual way and started to add these variables in some of my pull requests:

Isn't this the same question as #419?

@jgsogo
Copy link
Contributor Author

jgsogo commented Dec 12, 2019

Yes, I think #419 is exactly the same (more general and better explained). I'm closing this one then

@jgsogo jgsogo closed this as completed Dec 12, 2019
@conan-io conan-io locked as resolved and limited conversation to collaborators Dec 12, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants