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

[ZmnSCPxj]

Good morning Leo,

> The various hacks in the recipe to get a working build seem troublesome
> maintenance-wise, is it possible you think since you are a developer
> that you make the build scripts a bit more standard in the project?

Already working on that, but 0.10.0 will release soon and I doubt my changes 
will make it by then, so Guix might get c-lightning to 0.10.1 or later if we 
wait for it.

> I see there's some vendored libraries: gheap, jsmn, libbacktrace,
> libsodium, libwally-core ; Is it possible to unvendor those and create
> separate packages for each of them? Or is there a requirement of strict
> behavior here, either way, you could also create separate packages for
> each of them even if those are specific to c-lightning. It would make
> the main recipe cleaner, since as far as I can see it's also why the
> build system is so stubborn to GNU Guix? That it also attempts to build
> vendored libraries?

I think it is more the custom `configure` script.
The custom `configure` script also compiles a ***C*** program that then 
generates the configuration for the `ccan` library of the project, meaning 
cross-compilation requires special work for C-Lightning.
And `configure` does not call `configure` of the included libraries as well.

Yes, it is true that there is something of a requirement of a strict behavior 
here, I suppose it is possible to use `git-fetch` instead of `url-fetch` for 
our external libraries.
How do I generate `guix hash` for `git-fetch`ed `source`s?
However it also means that every release of C-Lightning I have to go 
double-check what git commit to use for each library (though `jsmn` and 
`libbacktrace` at least seem very stable).

But it looks to me that unvendoring will require more extensive patching of the 
`Makefile` and an even larger maintenance burden on Guix side?

`libwally-core` itself depends on another library `libsecp256k1`, so I suppose 
it must transitively be unvendored as well.

> Additionally, please do enable the test suite it's really valuable in
> GNU Guix.

The test suite is fairly large and can take a significant amount of time to run 
in full.

In addition, part of the test includes checks which take advantage of 
`BINTOPKGLIBEXECDIR` relative path we normally use, which I want to disable for 
Guix at least since the relative path only has an advantage if the user wants 
to move the installation after-the-fact to a different location (and on Guix 
the "installation" path cannot be moved anyway).
Using an absolute `BINTOPKGLIBEXECDIR` gives an advantage as mentioned in the 
comments that a profile being upgraded from one version of C-Lightning to 
another does not cause problems for daemons currently running off the profile.
The test can be disabled (but not easily), I suppose.

> I can help packaging the necessary Python dependencies, also we have a
> Python importer, e.g. "$ guix import pypi -r <pkg>" to help us go
> faster at it.

Please do, I am not very familiar with any Python infrastructure and am 
primarily a C programmer here, I just barely hack together some kind of test in 
Python.


Regards,
ZmnSCPxj