[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Guile, Guix, and C extensions

From: Stephen Scheck
Subject: Guile, Guix, and C extensions
Date: Mon, 30 Mar 2020 15:36:47 -0400


I am working on a couple of C extension modules for Guile, and I'd like to
offer end-users a
quality installation experience. Towards that end, I plan on initially
supporting two
installation mechanisms - the traditional GNU Autotools process, and Guix.

I am looking for guidance on best practices for packaging Guile modules
predominantly in C. Supporting Autotools seems fairly straightforward
(although there
are also some different possibilities for that as well), but what concerns
me most is Guix.

I made a quick survey of a few existing Guile C extension modules, and it
seems like there are
a couple of different strategies and assumptions being made out there about
what the right
way it is to package up a C module for installation into a Guix
environment. I also saw mention
of known bugs in Guile packaging for Guix in a thread on here recently, and
have noticed some
peculiarities with my own experiments - perhaps the same bug?

The Guix module definition for my projects is unsurprising - it uses
`gnu-build-system` to invoke
the Autotools sequence. It is here where I'm not sure what the configure
script should be doing,
and how to implement it so that it works well in both the Guix context, and
for ordinary GNU
installations without Guix.

Here are a couple of observations:

1) If I use the Guile `GUILE_SITE_DIR` Autoconf macro to provide locations
of Guile's site, compiled code, and dynamic library extension directories,
installation of the package fails because it tries to install these into
Guile's own directory in the Guix store, which I believe is prohibited,
because Guix wants to maintain atomic, immutable, reproducible and
verifiable installations of each package. But what's more, not only does it
do that, but it is using the *wrong* Guile ... it resolves to the
/var/guix/profiles/system/profile Guile instead of the Guile installed into
the active profile for the current user.

2) If I don't use `GUILE_SITE_DIR`, I can arrange for the Autotools
installation to install files into
a structure such as:


This nicely results in symlinks pointing into the module store directory
being populated into the following directories:


I think this is close to what should be the correct result, but it doesn't
quite work because `extensiondir` in %guile-build-info` points into the
store directory for Guile, so the compiled C dynamic libraries cannot be
located. This is also the case for the site-ccache and Scheme code
directories, but `GUILE_LOAD_PATH` gets set to the right place in the shell
environment, so uncompiled Scheme code at least gets found. I can work
around for dynamic libraries by setting a GUILE_SYSTEM_EXTENSIONS_PATH
environment variable to point into

So - the question is - how *should* this all work, and how should C
extension module authors set up their build scripts to do the right (best)
thing, while still behaving in a sane way for non-Guix installations?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]