ef49a11 build: allow static or shared but not both (Cory Fields) 36b0adf build: remove warning until it's reproducible (Cory Fields) Pull request description: Continuing from here: #1224 (comment) Unfortunately it wasn't really possible to keep a clean diff here because of the nature of the change. I suggest reviewing the lib creation stuff in its entirety, sorry about that :\ Rather than allowing for shared and static libs to be built at the same time like autotools, this PR switches to the CMake convention of allowing only 1. A new `BUILD_SHARED_LIBS` option is added to match CMake convention, as well as a `SECP256K1_DISABLE_SHARED` option which overrides it. That way even projects which have `BUILD_SHARED_LIBS=1` can opt-into a static libsecp in particular. Details: Two object libraries are created: `secp256k1_asm` and `secp256k1_precomputed_objs`. Some tests/benchmarks use the object libraries directly, some link against the real lib: `secp256k1`. Because the objs don't know what they're going to be linked into, they need to be told how to deal with PIC. The `DEFINE_SYMBOL` property sets the `DLL_EXPORT` define as necessary (when building a shared lib) ACKs for top commit: hebasto: re-ACK ef49a11, only [suggested](#1230 (review)) changes since my recent [review](#1230 (review)). real-or-random: ACK ef49a11 Tree-SHA512: 8870de305176fdb677caff0fdfc6f8c59c0e906489cb72bc9980e551002812685e59e20d731f2a82e33628bdfbb7261eafd6f228038cad3ec83bd74335959600

build: Meta-issue for follow-ups to initial CMake merge (#1113) #1224

Description

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions