12:32 < sipa> With cmake, the build artefacts seem to end up in build/src/, while I’d expect them in build/.
Implemented in this PR.
On Windows, this also simplifies running examples, because the DLL must resides either in the same folder where the executable is or somewhere in PATH.
hebasto force-pushed
on Mar 10, 2023
real-or-random
commented at 9:13 am on March 10, 2023:
contributor
Hm, I don’t know. This seems a bit arbitrary.
If we now deviate from putting the artifacts in their respective source directory anyway, and setting the artifact path is just setting a variable, would it make sense to also just put anything in ${PROJECT_BINARY_DIR} (or in a dedicated subdir of that)?
hebasto
commented at 9:49 am on March 10, 2023:
member
Hm, I don’t know. This seems a bit arbitrary.
Agree. But adding each path for every configuration to PATH, which is the case for multi-config, is really annoying.
If we now deviate from putting the artifacts in their respective source directory anyway, and setting the artifact path is just setting a variable, would it make sense to also just put anything in ${PROJECT_BINARY_DIR} (or in a dedicated subdir of that)?
Like ${PROJECT_BINARY_DIR}/out? Or ${PROJECT_BINARY_DIR}/bin?
real-or-random
commented at 10:09 am on March 10, 2023:
contributor
Agree. But adding each path for every configuration to PATH, which is the case for multi-config, is really annoying.
Indeed. It’s also annoying for devs on Windows (though noone uses Windows right now…)
Like ${PROJECT_BINARY_DIR}/out? Or ${PROJECT_BINARY_DIR}/bin?
Yeah, I had something like this in mind. out is probably a bit nicer because bin looks wrong for .so etc. Just not convinced it’s worth it. Having a subdir is a cheap and feels tiny bit cleaner because it avoids name collisions with existing files (e.g., what if we have a binary examples). Though in that case, autotools would break anyway… I guess there’s no clear right or wrong here, but if we want to move all artifacts to a single location, then ${PROJECT_BINARY_DIR} is probably good enough, and then it matches the autotools behavior at least. As discussed in IRC, we don’t care much and should do whatever makes things easier.
cmake: Move runtime output artifacts to `${PROJECT_BINARY_DIR}`
This change (1) simplifies running examples on Windows, because the DLL
must resides either in the same folder where the executable is or
somewhere in PATH; and (2) mimics Autotools-based build system behavior.
46ecb3663c
ci: Drop no longer needed code9dae69259b
hebasto force-pushed
on Mar 10, 2023
hebasto renamed this:
cmake: Move example binaries to `${PROJECT_BINARY_DIR}/src`
cmake: Move runtime output artifacts to `${PROJECT_BINARY_DIR}`
on Mar 10, 2023
hebasto
commented at 6:27 pm on March 10, 2023:
member
… if we want to move all artifacts to a single location, then ${PROJECT_BINARY_DIR} is probably good enough, and then it matches the autotools behavior at least.
Done.
The PR description has been updated (friendly ping @sipa :D ).
hebasto marked this as a draft
on Apr 12, 2023
hebasto
commented at 11:16 am on April 12, 2023:
member
Converted to draft for now.
theuni
commented at 2:37 pm on April 27, 2023:
contributor
Rather than setting the PATH in CI, can we set it in CMake for make check?
real-or-random
commented at 2:38 pm on April 27, 2023:
contributor
Rather than setting the PATH in CI, can we set it in CMake for make check?
I think this makes sense, and then Concept NACK on moving the binaries
This is a metadata mirror of the GitHub repository
bitcoin-core/secp256k1.
This site is not affiliated with GitHub.
Content is generated from a GitHub metadata backup.
generated: 2024-11-21 15:15 UTC
This site is hosted by @0xB10C More mirrored repositories can be found on mirror.b10c.me