44b205e9ee Revert "cmake: configure libsecp256k1.pc during install" (Daniel Pfeifer)
Pull request description:
This reverts commit 7106dce6fd.
This causes a regression for packaging, as the generated `.pc` file will contain the location that was used to build the package archive.
ACKs for top commit:
real-or-random:
ACK 44b205e9ee
Tree-SHA512: f4331c23534260bc21e69ccff65abad766e6a51aaba350c40674e32b3200768ca3c6742671e425aa8fcb681deb430cd6b3e20f34b9e8f8ab909371cf5e8976c5
0dfe387dbe cmake: support the use of launchers in ctest -S scripts (Daniel Pfeifer)
Pull request description:
When `CTEST_USE_LAUNCHERS` is set to `ON` in a `ctest -S` script, the configure step fails with the error message:
```
CMake Error:
CTEST_USE_LAUNCHERS is enabled, but the RULE_LAUNCH_COMPILE global property
is not defined.
Did you forget to include(CTest) in the toplevel CMakeLists.txt ?
```
However, `include(CTest)` produces unwanted clutter. `include(CTestUseLaunchers)` is a more lightweight alternative.
To reproduce the issue, run the following script with and without the PR applied.
```cmake
#!/usr/bin/env -S ctest -VV -S
set(CTEST_SOURCE_DIRECTORY "/path/to/secp256k1")
set(CTEST_BINARY_DIRECTORY "/path/to/secp256k1-build")
set(CTEST_CMAKE_GENERATOR "Ninja")
set(CTEST_USE_LAUNCHERS ON)
ctest_empty_binary_directory(${CTEST_BINARY_DIRECTORY})
ctest_start("Experimental")
ctest_configure()
ctest_build()
```
ACKs for top commit:
hebasto:
ACK 0dfe387dbe.
Tree-SHA512: 643d0fabd19ddfd5a64a0b34cfcca8ea2cff64438ee3441ba9a1745618daf99c468ec201ea6992c542d4e33152f4833691c42c8a90301fe3dfc3f0f49f755e55
This reverts commit 7106dce6fd.
This causes a regression for packaging, as the generated
`.pc` file will contain the location that was used to build
the package archive.
7106dce6fd cmake: configure libsecp256k1.pc during install (Daniel Pfeifer)
Pull request description:
When installing to a given prefix, make sure that the .pc file contains that prefix rather than the value of `CMAKE_INSTALL_PREFIX` that the project was configured with.
ACKs for top commit:
real-or-random:
ACK 7106dce6fd I verified that it fixes the path in libsecp256k1.pc
Tree-SHA512: 34841513d2dc52234718eab56ecb9224aa1e13ad2d13cd103624b355e0627c37441363ad24293e07da7a748191e6ed2b67649b489bf874bab35346146b78c16f
When installing to a given prefix, make sure that the .pc file contains
that prefix rather than the value of CMAKE_INSTALL_PREFIX that the
project was configured with.
37dd422b5c cmake: Emulate Libtool's behavior on FreeBSD (Hennadii Stepanov)
Pull request description:
Building the master branch @ f24b838bed on FreeBSD 14.3:
- with Autotools:
```
$ ./autogen.sh
$ ./configure --disable-static --prefix /tmp/AUTOTOOLS
$ gmake
$ gmake install
$ tree /tmp/AUTOTOOLS/lib
/tmp/AUTOTOOLS/lib
├── libsecp256k1.la
├── libsecp256k1.so -> libsecp256k1.so.5.0.1
├── libsecp256k1.so.5 -> libsecp256k1.so.5.0.1
├── libsecp256k1.so.5.0.1
└── pkgconfig
└── libsecp256k1.pc
2 directories, 5 files
```
- with CMake:
```
$ cmake -B build -DCMAKE_INSTALL_PREFIX=/tmp/CMAKE
$ cmake --build build
$ cmake --install build
$ tree /tmp/CMAKE/lib
/tmp/CMAKE/lib
├── cmake
│ └── libsecp256k1
│ ├── libsecp256k1-config-version.cmake
│ ├── libsecp256k1-config.cmake
│ ├── libsecp256k1-targets-relwithdebinfo.cmake
│ └── libsecp256k1-targets.cmake
├── libsecp256k1.so -> libsecp256k1.so.5
├── libsecp256k1.so.5
└── pkgconfig
└── libsecp256k1.pc
4 directories, 7 files
```
With this PR:
```
$ cmake -B build -DCMAKE_INSTALL_PREFIX=/tmp/CMAKE+PR
$ cmake --build build
$ cmake --install build
$ tree /tmp/CMAKE+PR/lib
/tmp/CMAKE+PR/lib
├── cmake
│ └── libsecp256k1
│ ├── libsecp256k1-config-version.cmake
│ ├── libsecp256k1-config.cmake
│ ├── libsecp256k1-targets-relwithdebinfo.cmake
│ └── libsecp256k1-targets.cmake
├── libsecp256k1.so -> libsecp256k1.so.5
├── libsecp256k1.so.5 -> libsecp256k1.so.5.0.1
├── libsecp256k1.so.5.0.1
└── pkgconfig
└── libsecp256k1.pc
4 directories, 8 files
```
From [FreeBSD Developers' Handbook](https://docs.freebsd.org/en/books/developers-handbook/policies/#policies-shlib):
> If you are adding shared library support to a port or other piece of software that does not have one, the version numbers should follow these rules. Generally, the resulting numbers will have nothing to do with the release version of the software.
>
> For ports:
>
> - Prefer using the number already selected by upstream
>
> - If upstream provides symbol versioning, ensure that we use their script
ACKs for top commit:
real-or-random:
utACK 37dd422b5c
Tree-SHA512: b603d7e293ae1fb15c2b3c05957dcc3cbe94294083ad1d8cb00b06b0e295597fa09719d32c18d628670952b6d00467f5bc884be9ab791baf59ec265e26032470
145ae3e28d cmake: add a helper for linking into static libs (Cory Fields)
Pull request description:
As discussed here: https://github.com/bitcoin-core/secp256k1/pull/1674#issuecomment-2934819801
Parent projects (Bitcoin Core in this case) may wish to include secp256k1 in another static library (libbitcoinkernel) so that users are not forced to bring their own static libsecp256k1.
Unfortunately, CMake lacks the machinery to link (combine) one static lib into another.
To work around this, secp256k1_objs is exposed as an interface library which parent projects can "link" into static libs.
ACKs for top commit:
hebasto:
ACK 145ae3e28d, tested on Ubuntu 24.04 using cmake 3.22.6 and the default cmake 3.28.3.
stickies-v:
Light ACK 145ae3e28d
Tree-SHA512: bfe72e3f337eadce8bdbe613e4ce2f2cd92046f811c447311e5670af9d52dbf5b9dc91866f69251f52a7632ad66d6df102fb6f4c1de2688bb7611b7b42e969a3
819210974b README: add link to musig example, generalize module enabling hint (Sebastian Falbesoner)
Pull request description:
ACKs for top commit:
real-or-random:
ACK 819210974b
Tree-SHA512: 9bfc7e59f0b6c6bacc591abe9835d1e6129e4daf286b91b35fad83ddf7d870a534d83ce2c27165ed8612f05695a5f15a3ef7bebbcbe63a5fe843d4c0617ebc9f
Parent projects (Bitcoin Core in this case) may wish to include secp256k1
in another static library (libbitcoinkernel) so that users are not forced
to bring their own static libsecp256k1.
Unfortunately, CMake lacks the machinery to link (combine) one static lib
into another.
To work around this, secp256k1_objs is exposed as an interface library which
parent projects can "link" into static libs..
3f31ac43e0 doc: Promote "Building with CMake" to standard procedure (Hennadii Stepanov)
Pull request description:
The CMake-based build system has demonstrated its maturity through its use in Bitcoin Core 29.0.
ACKs for top commit:
real-or-random:
utACK 3f31ac43e0
Tree-SHA512: be83494b60f4fd3ff08f4199d9cda4663b89efff32f3ec3bb856843707eeb6592ffdc6c84fdc18242cad422795901fb21e13cb15edd23a5d9cf2784324f8f7e0
3af71987a8 cmake: Bump minimum required CMake version to 3.22 (Hennadii Stepanov)
Pull request description:
Ubuntu 20.04 LTS has [reached](https://wiki.ubuntu.com/Releases) the End of Standard Support. There no longer appear to be compelling reasons to maintain compatibility with CMake 3.16.
The new suggested minimum, CMake 3.22, is shipped with Ubuntu 22.04 LTS, which is supported until April 2027.
This PR also introduces new CMake policies, from CMP0098 to CMP0128. Some of these may warrant the reviewers' attention:
- [CMP0099: Link properties are transitive over private dependencies of static libraries.](https://cmake.org/cmake/help/latest/policy/CMP0099.html)
- [CMP0117: MSVC RTTI flag /GR is not added to CMAKE_CXX_FLAGS by default.](https://cmake.org/cmake/help/latest/policy/CMP0117.html)
- [CMP0126: set(CACHE) does not remove a normal variable of the same name.](https://cmake.org/cmake/help/latest/policy/CMP0126.html)
- [CMP0128: Selection of language standard and extension flags improved.](https://cmake.org/cmake/help/latest/policy/CMP0128.html)
ACKs for top commit:
real-or-random:
utACK 3af71987a8
Tree-SHA512: f0c70dd5beafe830513895f076cafa6902dfcaab79d40bf9e7b27f14d9c4818f91d75f6aa993ba843f1d28ccd13cf466ad11dca46ca022cab1b43aace17d3ff7
Ubuntu 20.04 LTS has reached the end of standard support. There no
longer appear to be compelling reasons to maintain compatibility with
CMake 3.16.
The new suggested minimum, CMake 3.22, is shipped with Ubuntu 22.04 LTS,
which is supported until April 2027.
This change also introduces new CMake policies, from CMP0098 to CMP0128.
20b05c9d3f configure: Show exhaustive tests in summary (Tim Ruffing)
Pull request description:
ACKs for top commit:
hebasto:
ACK 20b05c9d3f, it aligns now with the CMake script: e56716a3bc/CMakeLists.txt (L348-L350)
sipa:
utACK 20b05c9d3f
jonasnick:
ACK 20b05c9d3f
Tree-SHA512: 30744ea5e5b7441ad252868c83cebfec2b02b75786b9ea55d4b0b0a696f1c7df39c48c243b29b13839a9f3a7757c192da8be0dd95412678a7583b123db6e99ac
1b6e081538 include: remove WARN_UNUSED_RESULT for functions always returning 1 (Jonas Nick)
Pull request description:
This makes the usage of the atribute consistent. In the musig and ellswift module, functions that return 1 always already don't have the WARN_UNUSED_RESULT attribute. In secp256k1.h and the extrakeys module, this has only been the case partially.
In all cases where this was removed, the function only returns 0 if the illegal callback has been called.
Fixes#1379
ACKs for top commit:
real-or-random:
utACK 1b6e081538
sipa:
utACK 1b6e081538
Tree-SHA512: 5d1f2563ddde34fb721dd0b96622e0888a9c72f95af6f1c8a94f7f1f72ca934b6af98a3357c1e922d8611a9869264bb0f3ceb7bed0164c6c3a6f92f9950d4f19
d87c3bc58f ci: Fix exiting from ci.sh on error (Tim Ruffing)
Pull request description:
Fixes the following bash error when make fails:
./ci/ci.sh: line 100: return: can only `return' from a function or
sourced script
ACKs for top commit:
hebasto:
ACK d87c3bc58f
Tree-SHA512: 5ecd0f550f7659cc41b403fdb7d5d3d37d1a167d585cca02b0aca209c8b9592bb3067cf11aeb80775666e7232f31bf05cf1bb97fec8c67f3bc5fe2243ddbbcfa
This makes the usage of the atribute consistent. In the musig and ellswift
module, functions that return 1 always already don't have the WARN_UNUSED_RESULT
attribute. In secp256k1.h and the extrakeys module, this has only been the case
partially.
In all cases where this was removed, the function only returns 0 if the illegal
callback has been called.
