Merge bitcoin-core/secp256k1#1696: build: Refactor visibility logic and add override
c82d84bb86build: add CMake option for disabling symbol visibility attributes (Cory Fields)ce7923874fbuild: Add SECP256K1_NO_API_VISIBILITY_ATTRIBUTES (Tim Ruffing)e5297f6d79build: Refactor visibility logic (Tim Ruffing) Pull request description: This is less invasive than #1695. The latter might be the right thing in a new library (and then we'd probably not support autotools in the first place), but any semantic change to this code has the potential to create news bug, or at least breakages for downstream users. This is different from #1677 in that it does not set `hidden` explicitly. I agree with the comment in #1677 that setting `hidden` violates the principle of least surprise. So this similar in spirit to #1674. So I wonder if this should also include3eef7362c4. I'd say no, `fvisibility` should then set by the user. But can you, in CMake, set `CMAKE_C_VISIBILITY_PRESET` from a parent project? ACKs for top commit: hebasto: ACKc82d84bb86, I have reviewed the code and it looks OK. Tree-SHA512: dad36c32a108d813e8d4e1849260af43f79a9aa8fbfb9a42b07d737e0467924a511110df0a2c6761539a1587b617a1b11123610a3db9d4cdf2b985dfb3eb21da
This commit is contained in:
@@ -54,6 +54,10 @@ add_library(secp256k1_precomputed OBJECT EXCLUDE_FROM_ALL
|
||||
# from being exported.
|
||||
target_sources(secp256k1 PRIVATE secp256k1.c $<TARGET_OBJECTS:secp256k1_precomputed>)
|
||||
|
||||
if(NOT SECP256K1_ENABLE_API_VISIBILITY_ATTRIBUTES)
|
||||
target_compile_definitions(secp256k1 PRIVATE SECP256K1_NO_API_VISIBILITY_ATTRIBUTES)
|
||||
endif()
|
||||
|
||||
# Create a helper lib that parent projects can use to link secp256k1 into a
|
||||
# static lib.
|
||||
add_library(secp256k1_objs INTERFACE)
|
||||
|
||||
Reference in New Issue
Block a user