cmake: Set top-level target output locations #1553

While testing #1551, I noticed that when cross-compiling a shared library with examples for Windows, the ctest fails to run examples with Wine. Adjusting the PATH variable in https://github.com/bitcoin-core/secp256k1/blob/4af241b32099067464e015fa66daac5096206dea/examples/CMakeLists.txt#L16-L18 does not help because WINEPATH is expected.

Another issue with the current implementation is that the examples cannot run individually on Windows.

This PR resolves both issues by reverting the implementation from #1290 in favour of the reworked and improved implementation from #1233.

ACK 3779472074d29125c06b715787005f3ac4f95cdf

It's probably a good idea that the binaries just work without the need to set a PATH. And it's okay to collect all binary artifacts in a single directory, we don't have that many.

What are your commands for building on wine?

What are your commands for building on wine?

On Ubuntu 24.04 with the wine-binfmt package installed:

$ cmake -B build --toolchain cmake/x86_64-w64-mingw32.toolchain.cmake -DSECP256K1_BUILD_EXAMPLES=ON
$ cmake --build build
$ ctest --test-dir build
Internal ctest changing into directory: /home/hebasto/git/secp256k1/secp256k1/build
Test project /home/hebasto/git/secp256k1/secp256k1/build
    Start 1: noverify_tests
1/6 Test [#1](/bitcoin-core-secp256k1/1/): noverify_tests ...................   Passed   52.72 sec
    Start 2: tests
2/6 Test [#2](/bitcoin-core-secp256k1/2/): tests ............................   Passed  111.58 sec
    Start 3: exhaustive_tests
3/6 Test [#3](/bitcoin-core-secp256k1/3/): exhaustive_tests .................   Passed    8.01 sec
    Start 4: ecdsa_example
4/6 Test [#4](/bitcoin-core-secp256k1/4/): ecdsa_example ....................   Passed    1.35 sec
    Start 5: ecdh_example
5/6 Test [#5](/bitcoin-core-secp256k1/5/): ecdh_example .....................   Passed    1.34 sec
    Start 6: schnorr_example
6/6 Test [#6](/bitcoin-core-secp256k1/6/): schnorr_example ..................   Passed    1.32 sec

100% tests passed, 0 tests failed out of 6

Total Test time (real) = 176.31 sec
$ ./build/bin/schnorr_example.exe 
Is the signature valid? true
Secret Key: 0x964362f6515fbb691dee49b936c8ba46dadd505eb4aa27f5db9b1ccf510f04a8
Public Key: 0x286123fee26ecfc75ec8bd6d4e175a9b4fa729e7d2bcd4034661a33dee600d80
Signature: 0xef0aa23ae13fd06710e31204a7a8ab52f0b726159b3cb2344c090220ed32d6dda958c9f7b3383c3fa7524a7f7ed54bf381c8a3bab1f8561072887dae6bf7bfe1

implementation from #1233.

cc @theuni

implementation from #1233.

cc @theuni

Friendly ping @theuni :)

Rebased.

I'm not sure what I'm missing here. Why does moving from src/ to bin/ fix anything? And mirroring the source tree is kinda the convention for CMake, no? I'd expect to find them in src/ anyway.

Why does moving from src/ to bin/ fix anything?

Moving built binaries from both src/ and example/ to bin/ does fix the issue because it places the executable and its dependency DLL in the same folder.

FWIW, we have a similar issue with the libbitcoinkernel shared library in Bitcoin Core.

And mirroring the source tree is kinda the convention for CMake, no?

It's the default behaviour adopted by many projects. However, here is a code snippet from the LLVM project:

set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX})
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX})

Here is a quote from Professional CMake: A Practical Guide 19th Edition, section 43.5.2, about the *_OUTPUT_DIRECTORY properties:

A common use of these target properties is to collect libraries and executables together in a similar directory structure as they would have when installed. This is helpful if applications expect various resources to be located at a particular location relative to the executable’s binary. On Windows, it can also simplify debugging, since executables and DLLs can be collected into the same directory, allowing the executables to find their DLL dependencies automatically (this isn’t needed on other platforms, since RPATH support embeds the necessary locations in the binaries themselves).

Ok, I see. I think (from googling) the part that I was missing is that dll's are put in CMAKE_RUNTIME_OUTPUT_DIRECTORY rather than CMAKE_LIBRARY_OUTPUT_DIRECTORY as I would've expected. Is that correct?

For Linux at least, .so's go to CMAKE_LIBRARY_OUTPUT_DIRECTORY.

Ok, I see. I think (from googling) the part that I was missing is that dll's are put in CMAKE_RUNTIME_OUTPUT_DIRECTORY rather than CMAKE_LIBRARY_OUTPUT_DIRECTORY as I would've expected. Is that correct?

This matches the CMake docs: The file is a "runtime" output when add_library() is called with the SHARED option (which may be implied), and it's a "library" output when add_library() is called with MODULE (which is intended for modules/plugins loaded dynamically at runtime.

• On non-DLL platforms: the shared library file (e.g. .so or .dylib) of a shared library target created by the add_library() command with the SHARED option.
• https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#runtime-output-artifacts

ping @theuni

Concept ACK and utACK c232486d84e21ece78b6cc956cd233cdf1bf8eee.

Discussed with @hebasto in person. We've decided to switch all of Core's CMake projects to use this layout (barring any unforeseen issues).

utACK c232486d84e21ece78b6cc956cd233cdf1bf8eee

This change might need a note in the CHANGELOG.md, no?

Changelog was added in #1631. Dropping "needs-changelog".