cmake: Emulate GNU Autotools 'make check -jN'

[hebasto]

It seems parallelism is requested for make check target when building with CMake and the "Unix Makefiles" generator which is the default on Linux and macOS. See:

• https://gnusha.org/secp256k1/2023-03-08.log:

13:53 < sipa> make -j check doesn't actually parallellize in the cmake build, which is a bit unfortunate

• build: Add CMake-based build system (6 of N) hebasto/bitcoin#15 (comment):

Is make check being run with multiple jobs? I assume not

With this PR, it is possible to build like that:

cmake -S . -B  build
make -C build -j $(nproc)
make check -C build -j $(nproc)

Making this PR a draft as it seems low priority and the diff seems a bit hackish.

My personal preference is to use the CMake's native ctest command :)

Anyway, this PR fixes an item in #1235.

---

UPD. Here is a couple of alternative approaches:

• set the CTEST_PARALLEL_LEVEL environment variable:

export CTEST_PARALLEL_LEVEL=$(nproc)

• use the test target and (undocumented) ARGS variable:

make test -C build ARGS=-j$(nproc)

[real-or-random]

Passing $MAKEFLAGS to ctest is indeed pretty hackish (and ctest doesn't like -j without an integer and some users have more MAKEFLAGS set in their env...)

[real-or-random]

My personal preference is to use the CMake's native ctest command :)

Yep, we should just update the CMake build docs in the README. We could even remove the "make check" emulation entirely if this is more CMake-ish. What do you think?

[hebasto]

My personal preference is to use the CMake's native ctest command :)

Yep, we should just update the CMake build docs in the README. We could even remove the "make check" emulation entirely if this is more CMake-ish. What do you think?

As we discussed at CoreDev, it would be better for the common good to use a unified approach for both projects, Bitcoin Core and libsecp256k1. A similar discussion is currently taking place in Bitcoin Core (here, here and here). Regarding your question, I think it would be advisable to ask for the opinions of developers who expressed concerns about make check, namely @sipa and @fanquake.

[hebasto]

I've updated the PR description with a couple of alternatives.

[real-or-random]

As we discussed at CoreDev, it would be better for the common good to use a unified approach for both projects, Bitcoin Core and libsecp256k1

@hebasto Has been any progress on this point in Core?

[hebasto]

As we discussed at CoreDev, it would be better for the common good to use a unified approach for both projects, Bitcoin Core and libsecp256k1

@hebasto Has been any progress on this point in Core?

In the https://github.com/hebasto/bitcoin/tree/cmake-staging, we lean to use the native CMake's invocations in all scripts (CI, Guix etc). This approach is agnostic to the underlying build system, and make check parallelism issue is no longer a concern.

However, it might change in the future :)

[real-or-random]

In the hebasto/bitcoin@cmake-staging, we lean to use the native CMake's invocations in all scripts (CI, Guix etc). This approach is agnostic to the underlying build system, and make check parallelism issue is no longer a concern.

Let's stick with this for now. Then people can use ctest -j3 or ctest -j$(nproc) or they can also set CTEST_PARALLEL_LEVEL="$(nproc)" similar to MAKEFLAGS="-j($proc)". Just be aware that ctest -j (without an explicit int) doesn't have an effect.