[bug#47187] [PATCH] gnu: Add c-lightning.

[ZmnSCPxj via Guix-patches via <guix-patches@gnu.org>]

Good morning Leo,

> On Thu, 2021-03-18 at 16:54 +0000, ZmnSCPxj wrote:
>
> > That would not be simple I think, but let me see what can be done.
> > For one, it would be fairly difficult to test it outside of a patched
> > Guix, as the packages are not usually available in most distros
> > (which is why we ship the source build with them); e.g. we do not
> > know how to actually find the "system" libbacktrace as no existing
> > system I know of actually ships the libbacktrace we use (Debian ships
> > a libbacktrace for android development, and is not the same package
> > as what we use).
> > Of the external packages we use, only libsodium is available on
> > Debian (and older Debian/Ubuntu, as mentioned, have an older version
> > that does not have a functionality we require, which is why it is
> > included in our source build as well), so that is the only external
> > we have that we can plausibly say "we can use the system version",
> > because all the others are not available on most systems.
>
> We can package every of those in GNU Guix, there's not as much
> bureaucracy as Debian when it comes to inclusion, as long as Free
> Software and freedom-non-controversial. The "system" thing is just so
> handy for us build-system wise we can just provide it as an input and
> it will find things automatically, I don't say that "system" lookup
> should imply to take any available library in general, in the context
> of GNU Guix we can give it a particular version and stick to it, unlike
> Debian's who can't have or with great difficulty, multiple versions of
> the same library installed.

Okay.

It is somewhat unclear to me however how to discover where the library is located.
As far as I understand how autotools does it, it looks at some standard locations on `/`, but I am uncertain if that is how it actually works.

For example if `libwally-core` is separately packaged, obviously it would install into a `/gnu/store/*` via a `--prefix` override.
And if the dependent package were using autotools, it is somehow able to magically find where the `lib*.a` file is.
However, C-Lightning does not actually use autotools (its build system predated my participation, I offered to port to autotools but this was declined), so I somehow need to emulate what autotools does in `--use-system-libraries` mode.

I probably have to go hack some autotools package that trivially depends on `libwally-core` and see what the exact shell script is generated.

> Also if we want to provide the Python bindings (?) to c-lightning we
> also have the option of creating a separate package based on the same
> sources but with different build-system (like python-build-system), and
> also it can have c-lightning as an input.

Note that AFAIK the Python bindings do not actually invoke any of the C-Lightning binaries, they just open the UNIX socket to the c-lightning daemon, so I think there is no need for `c-lightning` itself as an input.

Regards,
ZmnSCPxj