Bundling the native library source

[psibi]

Right now, the library requires secp256k1 to be available in the system for it to build. This creates additional overhead for us when we use base Docker image( and also on the developer machine). Would the library be open to bundle the C code along with it which will be controlled via a cabal flag (the default being the current behaviour: using the system library).

I can send a PR for the same if the devs are okay about this.

[psibi]

Any update on this ?

[jprupp]

I used to have the library included like this. But I wasn't comfortable with the way I set the build up. If you are more comfortable with the build system and have a more elegant solution to embed the C code with the Haskell bindings then I will accept a pull request.

[psibi]

@xenog I looked on the git history to see the previous solution. I see that git submodule was used to track the upstream code and use a custom Setup.hs to buid it. In my experience I would prefer this solution instead of a custom Setup.hs:

• Include the C source code under cbits and adapt it for the secp256k1-haskell package. This may even include deleting some source codes which aren't exactly required for this package.
• Have a conditional cabl flag to make the package use the in-built C source code. The default would be to make it behave like the current behaviour: making it use the system library

Does that sound acceptable to you or would you prefer a custom Setup.hs route (I personally would prefer a simpler approach) ?

[jprupp]

There is some magic that happens in the original library. Some C code is generated via the upstream build script that is needed for it to work. I am not a C developer, nor do I have an interest in digging too deeply here, which is why I removed the library.