Conda recipe for libsecp256k1

[MementoRC]

Hello,

1.) I am interested in packaging the library for use in a conda environment. For this, I need to select the features to include in the package (this can be updated in future releases). Is it recommended to include all the features within the conda package?
Currently with the defaults features, the coincurve python binding package fails to build because it include RECOVERY. There are several ways of working around this, but I would rather do it the most practical way and in accordance with the authors

2.) One feature that conda packages use is pkg-config, and using the CMAKE build method, so I added something like this to the CMakeList.txt:

set(COMMENT_TITLE "${COMMENT_TITLE}")
set(COMMENT_COPYRIGHT "${COMMENT_COPYRIGHT}")
set(COMMENT_LICENCE "${COMMENT_LICENCE}")

set(PACKAGE_PREFIX "@prefix@")
set(PACKAGE_NAME "${PROJECT_NAME}")
set(PACKAGE_DESCRIPTION "${PROJECT_DESCRIPTION}")
set(PACKAGE_URL "${PROJECT_HOMEPAGE_URL}")
set(PACKAGE_VERSION "${PROJECT_VERSION}")
set(PACKAGE_CFLAGS "${SECP256K1_CFLAGS}")
set(PACKAGE_LDFLAGS "${SECP256K1_LDFLAGS}")

configure_file(${CMAKE_CURRENT_SOURCE_DIR}/${PROJECT_NAME}.pc.cmake.in ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.pc @ONLY)
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.pc DESTINATION lib/pkgconfig)

Does this look sensible?

Thank you

[real-or-random]

Currently with the defaults features, the coincurve python binding package fails to build because it include RECOVERY. There are several ways of working around this, but I would rather do it the most practical way and in accordance with the authors

Yes, the recovery module is not enabled by default. If you need it, the recommended way to enable it is to pass -DSECP256K1_ENABLE_MODULE_RECOVERY=ON to CMake, (or --enable-module-recovery to ./configure for the autotools build method). It's the only module which is not enabled by default.

2.) One feature that conda packages use is pkg-config, and using the CMAKE build method, so I added something like this to the CMakeList.txt:

Not exactly. If you look at https://github.com/bitcoin-core/secp256k1/blob/master/libsecp256k1.pc.in, other variables are necessary. Also SECP256K1_CFLAGS are the flags when building the library itself, not the flags necessary for linking against the library. But the latter is what you need for pkg-config.

I see two clean ways forward:

• We currently don't ship a pkg-config file in CMake builds because CMake uses a different system. But we ship a pkg-config file in autotools builds, so if you can switch to autotools, this will solve the problems. (But I see that Conda also targets Windows, and CMake is probably better on windows...)
• We could just ship the pkg-config file also in CMake builds. (@hebasto What do you think? I guess that won't hurt?!)

[MementoRC]

Thank you

Yes, the recovery module is not enabled by default. If you need it, the recommended way to enable it is to pass -DSECP256K1_ENABLE_MODULE_RECOVERY=ON to CMake, (or --enable-module-recovery to ./configure for the autotools build method). It's the only module which is not enabled by default.

Ok, the recipe will build all the modules

Not exactly. If you look at https://github.com/bitcoin-core/secp256k1/blob/master/libsecp256k1.pc.in, other variables are necessary. Also SECP256K1_CFLAGS are the flags when building the library itself, not the flags necessary for linking against the library. But the latter is what you need for pkg-config.

Well, the SECP256K1_CFLAGS was added to the CMakeList.txt and gathered this info:

Build type:
 - CMAKE_BUILD_TYPE ................... Release
 - CFLAGS ............................. -O2
 - LDFLAGS for executables ............ 
 - LDFLAGS for shared libraries ....... 

Then apart from the package location, that needs to be relative for a conda packages (since the package is installed ina user environment), the below should be working. I test-packaged the library in my channel, then installed in an environment to build coincurve - coincurve package then built without issues (I am also preparing a coincurve recipe)

#   SECP256K1 - C library for ECDSA
#   Copyright (c) 2013 Pieter Wuille
#   MIT

prefix=${pcfiledir}/../..
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: libsecp256k1
Description: Optimized C library for ECDSA signatures and secret/public key operations on curve secp256k1.
URL: https://github.com/bitcoin-core/secp256k1
Version: 0.4.0
Cflags: -I${includedir}  -O2
Libs: -L${libdir} -lsecp256k1

I see two clean ways forward:

• We currently don't ship a pkg-config file in CMake builds because CMake uses a different system. But we ship a pkg-config file in autotools builds, so if you can switch to autotools, this will solve the problems. (But I see that Conda also targets Windows, and CMake is probably better on windows...)
• We could just ship the pkg-config file also in CMake builds. (@hebasto What do you think? I guess that won't hurt?!)

Cool, I would rather use CMake, using autotools complicates the recipe a bit.

3. ) Now third question is whether you would like to add another maintainer from Bitoin-core team?

[hebasto]

• We could just ship the pkg-config file also in CMake builds. (@hebasto What do you think? I guess that won't hurt?!)

Please see #1422.

[real-or-random]

3. ) Now third question is whether you would like to add another maintainer from Bitoin-core team?

We typically leave this to downstream maintainers, but please don't hesitate to reach out in case of further packaging questions, now or in the future.

[MementoRC]

Great. I'll update the patch that I apply in the recipe for v0.4.0 for now. I still think that I would need to update the prefix, to make it relocatable in the user conda environment (using the relative path). Anyway, I am still novice in this conda recipies and for now awaiting feedback on the recipe submission.
Thank you for the diligent feedback