WIP: visibility example for cmake

[purpleKarrot]

Alternative to #1674 and #1677.

[purpleKarrot]

The fact that a build called "Windows (VS 2022, static)" is failing with the message "unresolved external symbol __imp_..." is concerning. The fact that private symbols cannot be resolved indicates that visibility is working correctly and that the library is not static. Unfortunately, the compiler command line is not visible on github, so this needs further investigation.

[real-or-random]

The fact that private symbols cannot be resolved indicates (...) that the library is not static.

I don't think so. It builds a ".lib" file: https://github.com/bitcoin-core/secp256k1/actions/runs/15979380201/job/45069998808?pr=1695#step:4:57

See also https://github.com/bitcoin-core/secp256k1/actions/runs/15965328923/job/45024576152#step:5:36, which shows that no ".dll" is created on master. (We should run file also on "*.lib" files...)

[real-or-random]

I suspect that building the exes fails because SECP256K1_STATIC is not actually set for some reason.

Unfortunately, the compiler command line is not visible on github, so this needs further investigation.

Yes, adding this to CI would be useful in any case.

[purpleKarrot]

The fact that private symbols cannot be resolved indicates (...) that the library is not static.

I don't think so. It builds a ".lib" file: https://github.com/bitcoin-core/secp256k1/actions/runs/15979380201/job/45069998808?pr=1695#step:4:57

I don't find that convincing.

Creating library D:/a/secp256k1/secp256k1/build/lib/RelWithDebInfo/noverify_tests.lib and object D:/a/secp256k1/secp256k1/build/lib/RelWithDebInfo/noverify_tests.exp
  noverify_tests.vcxproj -> D:\a\secp256k1\secp256k1\build\bin\RelWithDebInfo\noverify_tests.exe
  secp256k1.vcxproj -> D:\a\secp256k1\secp256k1\build\lib\RelWithDebInfo\libsecp256k1.lib

This does not indicate that a static library for libsecp256k1 is created, it just means that noverify_tests links against libsecp256k1.lib, which could be a static library or an import library for an associated .dll. Both of these have the same file extension.

[real-or-random]

Ok, maybe this is more convincing:

• This output line from the "shared" job on master mentions the dll explicitly: https://github.com/bitcoin-core/secp256k1/actions/runs/15965328923/job/45024576149#step:4:53
• (Same for the "shared" job in this PR: https://github.com/bitcoin-core/secp256k1/actions/runs/15979380201/job/45069998798?pr=1695#step:4:56)
• But the corresponding output line from the "static" job doesn't mention the dll: https://github.com/bitcoin-core/secp256k1/actions/runs/15979380201/job/45069998808?pr=1695#step:4:57

[purpleKarrot]

I see the issue. The usage requirements of the secp256k1 target are not applied, because benchmarks and tests don't actually build against that target. They build against secp256k1_precomputed and secp256k1_asm instead.

[theuni]

A few things:

1. As discussed in the other PRs, it's clear that this would be much simpler if we only supported CMake, but that's unfortunately not the reality at the moment. The majority of the cruft in the header exists to support the combination of buildsystems.
2. Could you please split this into refactor vs behavioral change commits for easier review? There's a lot going on here and the some of the rationale isn't obvious at first glimpse.

[real-or-random]

If we don't use this approach in the end, we should recycle the CMake snippets code that sets SECP256K1_STATIC for the parent when consuming the library.