[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#47187] [PATCH] gnu: Add c-lightning.
From: |
ZmnSCPxj |
Subject: |
[bug#47187] [PATCH] gnu: Add c-lightning. |
Date: |
Fri, 19 Mar 2021 19:31:07 +0000 |
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
- [bug#47187] [PATCH] gnu: Add c-lightning., ZmnSCPxj, 2021/03/16
- [bug#47187] [PATCH] gnu: Add c-lightning., Léo Le Bouter, 2021/03/16
- [bug#47187] [PATCH] gnu: Add c-lightning., Léo Le Bouter, 2021/03/16
- [bug#47187] [PATCH] gnu: Add c-lightning., ZmnSCPxj, 2021/03/16
- [bug#47187] [PATCH] gnu: Add c-lightning., Léo Le Bouter, 2021/03/16
- [bug#47187] [PATCH] gnu: Add c-lightning., ZmnSCPxj, 2021/03/16
- [bug#47187] [PATCH] gnu: Add c-lightning., Léo Le Bouter, 2021/03/18
- [bug#47187] [PATCH] gnu: Add c-lightning., ZmnSCPxj, 2021/03/18
- [bug#47187] [PATCH] gnu: Add c-lightning., Léo Le Bouter, 2021/03/19
- [bug#47187] [PATCH] gnu: Add c-lightning.,
ZmnSCPxj <=
- [bug#47187] [PATCH] gnu: Add c-lightning., Léo Le Bouter, 2021/03/21
- [bug#47187] [PATCH] gnu: Add c-lightning., Léo Le Bouter, 2021/03/26