cmake: Set top-level target output locations

[hebasto]

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

secp256k1/examples/CMakeLists.txt

Lines 16 to 18 in 4af241b

	set_tests_properties(${test_name} PROPERTIES
	ENVIRONMENT "PATH=$<TARGET_FILE_DIR:secp256k1>;$ENV{PATH}"
	)

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.

[real-or-random]

ACK 3779472

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.

[real-or-random]

What are your commands for building on wine?

[hebasto]

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: noverify_tests ...................   Passed   52.72 sec
    Start 2: tests
2/6 Test #2: tests ............................   Passed  111.58 sec
    Start 3: exhaustive_tests
3/6 Test #3: exhaustive_tests .................   Passed    8.01 sec
    Start 4: ecdsa_example
4/6 Test #4: ecdsa_example ....................   Passed    1.35 sec
    Start 5: ecdh_example
5/6 Test #5: ecdh_example .....................   Passed    1.34 sec
    Start 6: schnorr_example
6/6 Test #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

[fanquake]

implementation from #1233.

cc @theuni

[real-or-random]

implementation from #1233.

cc @theuni

Friendly ping @theuni :)

[hebasto]

Rebased.

[theuni]

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.

[hebasto]

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).

[theuni]

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.

[real-or-random]

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

[real-or-random]

ping @theuni

[theuni]

Concept ACK and utACK c232486.

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

[real-or-random]

utACK c232486

[hebasto]

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