Python linkage enhancements

[whitslack]

• On systems supporting Libtool (i.e., anything but Windows), skip compiling the "amalgamated" sources for the Python module and simply link in the just-built libwallycore.a and libsecp256k1.a.

• setup.py: support optionally building and linking to libwally-core as a dynamic shared object if WALLY_ABI_PY_WHEEL_USE_DSO=1 is set. Ignored on Windows, where setup.py does not build libwally-core.

[whitslack]

It should be possible to determine what args setup.py was called with I think, can you give me the calls that are made (and the arguments) by the Gentoo machinery?

@jgriffiths: This is the command line that Gentoo's distutils-r1.eclass invokes to build the libwally-core Python wheel:

gpep517 build-wheel --backend setuptools.build_meta:__legacy__ --output-fd 3 --wheel-dir /var/tmp/portage/net-libs/libwally-core-1.0.0/work/libwally-core-release_1.0.0-python3_11/wheel

And when I set DISTUTILS_EXT=1 like I'm supposed to for Python modules that include a native extension library, then before the above command the machinery runs this command to pre-build the extension before building the wheel:

python3.11 setup.py build_ext -j 5

Ostensibly the reason for splitting it out like that is so that the native library build can be parallelized, although in the case of libwally-core there is only one C source file (src/swig_python/swig_python_wrap.c), so there's no advantage, but I'll set DISTUTILS_EXT=1 anyway just to suppress the QA warning. EDIT: Gentoo no longer runs build_ext in advance but now rather sets DIST_EXTRA_CONFIG to the path of a config file that specifies the parallelism for the build_ext phase that runs as part of the normal wheel building process.

In either case, after building the wheel, the machinery runs this command to install it into a staging location:

gpep517 install-wheel --destdir=/var/tmp/portage/net-libs/libwally-core-1.0.0/work/libwally-core-release_1.0.0-python3_11/install --interpreter=/usr/bin/python3.11 --prefix=/usr --optimize=all /var/tmp/portage/net-libs/libwally-core-1.0.0/work/libwally-core-release_1.0.0-python3_11/wheel/wallycore-1.0.0-cp311-cp311-linux_x86_64.whl

I'm not sure if any of that helps you at all. (I rather doubt it.)

[whitslack]

@jgriffiths: Did this slip through the cracks, or have you decided not to support this after all?

[jgriffiths]

@whitslack yes it did. The python build machinery has been updated somewhat, so this will need re-working. Please submit under a new PR if you would.