Provide pkg-config compatible installation instructions

[ghost]

This PR provides some basic instructions and a simple configuration file to allow this library to be installed system-wide in such a way it can be found by tools relying on pkg-config to handle dependencies. This is the first step towards providing proper packaging I guess, but my skills in this domain are rather limited.

Note this PR is based on version 0.3.10 because that's what cardano-base depends on.

[dot-asm]

I'd say that a script would be more appropriate. A script that would accept the target prefix directory as an argument and emit the accordingly tailored .pc file. One can examine $PKG_CONFIG_PATH if no argument is passed. And one can use git tag --sort=v:refname to find the version. And with this in mind one can also make a case for making a temporary clone with the tag in question, so that everybody who runs the script would compile the same code, as opposed to the tip of the repo...

As for documentation. The reason for why C bindings are not "advertised," is because Rust and Go parallelize the operations, while the lack of the parallelization is viewed as a "not-for-production" quality. And I'd very much like to see this mentioned one way or another...

[dot-asm]

I'd say that a script would be more appropriate.

Say build/pkg-config-install.sh... Or .py...

[ghost]

Thanks for taking the time to review this. So do I understand you would be favorable to have a dedicated build script?

Also, could you elaborate on this

The reason for why C bindings are not "advertised," is because Rust and Go parallelize the operations, while the lack of the parallelization is viewed as a "not-for-production" quality.

? This seems pretty important to understand why this is the case and we should not use C bindings.

[dot-asm]

do I understand you would be favorable to have a dedicated build script?

Not a build, but a "clone-latest-tag-into-a-temp-dir, call-the-temp-dir/build.sh, copy-headers-and-.a-file, generate-the-.pc-file." I'm torn about the 1st step, it might be appropriate to provide an option to skip it...

This seems pretty important to understand why this is the case and we should not use C bindings.

It's 2023, even single-board computers are multi-core. BLS is relatively expensive computationally. Even single-signature verification is parallelizeable... Users have to recognize that C bindings is something to build upon further, like Rust and Go bindings do:-)

[dot-asm]

Users have to recognize that C bindings is something to build upon further

Just in case, it would be tedious to build further in C, C++[>=11] would be a way more suitable choice. One can argue that blst.hpp could do that... If only time permitted:-(

[dot-asm]

How about

#!/bin/sh

set -e

_IFS="$IFS"; IFS=':'
for dir in $PKG_CONFIG_PATH `pkg-config --variable pc_path pkg-config`; do
    if [ -d "${dir}" -a -w "${dir}" -a -d "${dir}/../../include" ]; then
        tgt="$dir"
        break
    fi
done
IFS="$_IFS"; unset _IFS

export tgt

if [ -z "${tgt}" ]; then
    echo "no suitable pkg-config directory found"
    exit 1
fi

cd ${TMPDIR:-/tmp}

trap 'rm -rf blst.$$' 0
git clone https://github.com/supranational/blst blst.$$
( trap '[ $? -ne 0 ] && rm "${tgt}/blst.pc" 2>/dev/null' 0
  cd blst.$$
  tag=`git tag --sort=v:refname | tail -1`
  git checkout --detach ${tag}
  ./build.sh "$@"
  cp libblst.a "${tgt}/.."
  cp bindings/blst.h* "${tgt}/../../include"
  cat > "${tgt}/blst.pc" << blst.pc
libdir=\${pcfiledir}/..
incdir=\${pcfiledir}/../../include
Name: blst
Version: $tag
Description: blst core library
Cflags: -I\${incdir}
Libs: -L\${libdir} -lblst
blst.pc
)

with suggestion to curl -sSf https://github.com/supanational/blst/blob/master/build/pkg-install.sh | sh after committing?

[dot-asm]

Please see #196.