Create bindings for all methods and static types in ellswift.h in
secp256k1-sys and their respective safe-rust types.
All methods are extensively commented and tested using BIP324's
test vectors
Licenses are boring as hell, so is are all the comments at the top of
each file. This patch makes no comment on the merit of license comments
in each file, rather this patch reduces the license comment to the
minimum possible with no loss of meaning - an SPDX license identifier.
Note also please that we remove the "written by" comments as well for
the following reasons (discussed recently on rust-bitcoin repo):
- they are not descriptive because many devs contributed
- they have a tendency to include the wrong date because of cut'n'pasta
- all this info is in the git history
ref: https://spdx.dev/ids/#how
Dunno why we haven't seen this elsewhere, but when trying to build
locally for an ARM embedded target `secp256k1-sys` failed to
compile as it was missing `string.h`, just like WASM.
This patch adds a trivial fallback - if we fail to compile
initially we unconditionally retry with the wasm-sysroot, giving us
a valid `string.h`.
Currently we are defining the WASM integer size and alignments in the
`stdio.h` header file, this is wrong because this file is included in
the build by way of `build.rs` as well as by upstream `libsecp256k1`.
Move WASM integer definitions to a `C` source file and build the file
into the binary if target is WASM.
cc-rs builds C dependencies with reduced visibility to avoid
exporting the C symbols all the way out to any rust-built shared
libraries however we override it with SECP256K1_API. We should
avoid doing this, allowing LTO/DCE to do its work.
This feature was not useful for Cargo users, since Cargo does not give you
the kind of fine-grained control over C library linkage that you need. So
it was just unnecessarily confusing and would cause the build to break if
you enabled it accidentally, say, with --all-features.
This is configurable in upstream now.
Fixes#214.
So far, this just sets it to `4`. It's tempting to set it to `2` when `lowmemory` is enabled
but `lowmemory` is about RAM and not about binary size. This is better addressed by
a resolution of #193.
libsecp256k1 really only barely uses libc at all, and in practice,
things like memcpy/memcmp get optimized into something other than a
libc call. Thus, if we provide simple stub headers, things seem to
work with wasm-pack just fine.