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
CMake: Respect BUILD_SHARED_LIBS #2755
Conversation
I am not sure about this (even though I actually prefer using standard ways of doing things) because it inverts the default we had. I feel that
But the CMake documentation says: "This variable is often added to projects as an OPTION so that each user of a project can decide if they want to build the project using shared or static libraries." |
|
@ruslo Appveyour should also be updated not to use CURL_STATICLIB |
Use standard CMake variable BUILD_SHARED_LIBS instead of introducing custom option CURL_STATICLIB. Use '-DBUILD_SHARED_LIBS=%SHARED%' in appveyor.yml.
Done |
Line 110 in 7bc1180
|
@bagder C++ part is not affected by this change, if(BUILD_SHARED_LIBS)
set(CURL_STATICLIB NO)
else()
set(CURL_STATICLIB YES)
endif()
# Use:
# * CURL_STATICLIB
configure_file(curl_config.h.cmake
${CMAKE_CURRENT_BINARY_DIR}/curl_config.h) |
LGTM |
Thanks! |
Use standard CMake variable BUILD_SHARED_LIBS instead of introducing custom option CURL_STATICLIB. Use '-DBUILD_SHARED_LIBS=%SHARED%' in appveyor.yml. Reviewed-by: Sergei Nikulov Closes curl#2755
Use standard CMake variable BUILD_SHARED_LIBS instead of introducing custom option CURL_STATICLIB. Use '-DBUILD_SHARED_LIBS=%SHARED%' in appveyor.yml. Reviewed-by: Sergei Nikulov Closes curl#2755
Use standard CMake variable BUILD_SHARED_LIBS instead of introducing
custom option CURL_STATICLIB.