Simple cmake build script #315
Conversation
|
Ping. |
|
Is there any means of testing this automatically? |
|
automatic builds are probably doable by Travis. However, I'm not familiar with Travis very much. But this PR is not production ready. I would like to know if you are interested. If yes we can discuss how to proceed. |
|
Anyone interested in this? |
|
The cmake script looks simple enough, but doesn't provide much flexibility. I'm fine with merging it as long as there is automated testing that makes sure it doesn't go stale over time, for each of its supported configurations. |
|
Ok, I will work on this. |
|
Sorry it takes so long... Do you want me to extend the Travis CI matrix with another dimension of "build system"? As an alternative I can propose using Circle CI for CMake builds. |
|
Unfortunately, we lack the resources or interest to adequately maintain another parallel build system on an ongoing basis. To the extent that build-system concerns would be a good use of development time, we believe that they'd better be spent making it easier to build the library without any build system and documenting how that's done. I believe we're likely to close any further cmake or vcproject pull requests unless something changes-- nothing wrong with your efforts and thank you for the attempt, they just don't reflect this libraries focus at this time. |
e1eb337 ci: Add "x86_64: Windows (VS 2022)" task (Hennadii Stepanov) 10602b0 cmake: Export config files (Hennadii Stepanov) 5468d70 build: Add CMake-based build system (Hennadii Stepanov) Pull request description: This PR adds a [CMake](https://cmake.org/)-based build system. Added build instructions and examples to the [`README.md`](https://github.com/hebasto/secp256k1/blob/220628-cmake/README.md#building-with-cmake-experimental) file. Ways to integrate with downstream CMake-based projects: - if `secp256k1` is a subtree (including Bitcoin Core project) -- `add_subdirectory(secp256k1)` - if `secp256k1` has been installed -- `find_package(secp256k1 0.2.1 CONFIG)`, see https://github.com/hebasto/secp256k1-CMake-example Added a few toolchain files for easy cross compiling. Discussions on IRC: - https://gnusha.org/secp256k1/2022-06-23.log - https://gnusha.org/secp256k1/2022-06-24.log - https://gnusha.org/secp256k1/2022-06-27.log - https://gnusha.org/secp256k1/2023-01-30.log --- Related PRs: - #315 - #549 - #761 --- **Implementation notes** Minimum required CMake version is 3.1. This was required to provide [`C_STANDARD`](https://cmake.org/cmake/help/latest/prop_tgt/C_STANDARD.html) property. In turn, this choice of CMake version implies it is not possible to build with default CMake on Debian 8, which has CMake v3.0.2 only. Also see: - [CMake Versions on Linux Distros](https://gitlab.kitware.com/cmake/community/-/wikis/CMake-Versions-on-Linux-Distros) - https://repology.org/project/cmake/versions --- # Autotools -- CMake Feature Parity Tables ## 1. Configuration options Autotool-based build system features being listed according to the `./configure --help` output. | Autotools | CMake | |---|---| | `--prefix` | `-DCMAKE_INSTALL_PREFIX` | `--enable-shared` | `-DSECP256K1_BUILD_SHARED` | | `--enable-static` | `-DSECP256K1_BUILD_STATIC` | | `--enable-dev-mode` _hidden_ | N/A, see #1113 (comment) | | `--enable-benchmark` | `-DSECP256K1_BUILD_BENCHMARK` | | `--enable-coverage` | `-DCMAKE_BUILD_TYPE=Coverage` | | `--enable-tests` | `-DSECP256K1_BUILD_TESTS` | | `--enable-ctime-tests` | `-DSECP256K1_BUILD_CTIME_TESTS` | | `--enable-experimental` | `-DSECP256K1_EXPERIMENTAL` | | `--enable-exhaustive-tests` | `-DSECP256K1_BUILD_EXHAUSTIVE_TESTS` | | `--enable-examples` | `-DSECP256K1_BUILD_EXAMPLES` | | `--enable-module-ecdh` | `-DSECP256K1_ENABLE_MODULE_ECDH` | | `--enable-module-recovery` | `-DSECP256K1_ENABLE_MODULE_RECOVERY` | | `--enable-module-extrakeys` | `-DSECP256K1_ENABLE_MODULE_EXTRAKEYS` | | `--enable-module-schnorrsig` | `-DSECP256K1_ENABLE_MODULE_SCHNORRSIG` | | `--enable-external-default-callbacks` | `-DSECP256K1_USE_EXTERNAL_DEFAULT_CALLBACKS` | | `--with-test-override-wide-multiply` _hidden_ | `-DSECP256K1_TEST_OVERRIDE_WIDE_MULTIPLY` | | `--with-asm` | `-DSECP256K1_ASM` | | `--with-ecmult-window` | `-DSECP256K1_ECMULT_WINDOW_SIZE` | | `--with-ecmult-gen-precision` | `-DSECP256K1_ECMULT_GEN_PREC_BITS` | | `--with-valgrind` | `-DSECP256K1_VALGRING` | A screenshot of grouped options from `cmake-gui`:  ## 2. `make` targets | Autotools | CMake | |---|---| | `make` | `make` | | `make check` | `make check` | | `make install` | `make install` * | * Installation of `lib/pkgconfig/libsecp256k1.pc` not implemented. ACKs for top commit: theuni: ACK e1eb337. sipa: ACK e1eb337 real-or-random: ACK e1eb337 Tree-SHA512: ebe2772eeb1a430a0a7ae767fb1a9a82d52d5e9bf2306956cd08f7b442c862be2539774dd10d5555817353d37d1c6add78b8fe5a85bb71239304fb42c98ff337
Greatings,
I'm working on building your library with cmake. In the end I plan to build it with Visual Studio.
If you were interested in that I would like to spend more time on improving build configs in general. E.g. we can query the compiler about 32/64 bit target architecture instead of checking that during autoconf step.
Share your opinions. Thanks.