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

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

Good morning Leo,

> On Wed, 2021-03-17 at 03:42 +0000, ZmnSCPxj wrote:
>
> > I understand.
> > This will require a largish amount of work I think.
> > Would this technique be acceptable?
> >
> > -   `add-before 'configure 'unvendor-externals`
> >     -   `rm -rf` the vendored externals.
> >     -   `ln -s` the needed `.h` and `.la`/`.a`/`.so` files from the
> >         `inputs` to the expected paths within the `external/` directory.
> >
> >
> > ?
>
> Maybe simply add an option like --with-system-libbacktrace etc. in the
> build system?

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.

Also --- we would be somewhat wary of taking the "system" `libsecp256k1`, as this is very consensus-critical, and we know that our program works with a very specific version, but cannot assure this to be true if the "system" `libsecp256k1` is not the exact version.
(Note that we cannot take the `libsecp256k1` from `bitcoin-core` because (1) the `bitcoin-core` package uses a vendored `libsecp256k1`, the separate Guix `libsecp256k1` is actually only used by `electrum` and related projects and (2) the interface `bitcoin-core` uses may be different from the interface we use, it would require review before we would be able to assure that the interfaces they use are exactly the same; this would be mitigated by running the full test suite as it also tests consensus-criticality.)
Is there an easy way to ensure that any `libsecp256k1` that gets fed into the `c-lightning` build as an `inputs` is of a specific `git` commit?

> And yes remove externals, I think that you should use a
> snippet in the origin field instead of a phase for that.

Hmm do you mean something like:

    (origin
      ; whatever...
      (snippet
        '(begin
           (delete-file-recursively "external/gheap")
           (delete-file-recursively "external/jsmn")
           (delete-file-recursively "external/libbacktrace")
           (delete-file-recursively "external/libsodium")
           (delete-file-recursively "external/libwally-core"))))

?

> > Incidentally, we also install some Python modules.
> > How do I "properly" export the Python modules within Guix?
>
> I will ask someone else here but you might have to mix the python-
> build-system in.

How do you mix in a build system?
Would `python-pyqt` be a good example of such "mix in"?

Regards,
ZmnSCPxj