[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 01/01: services: Add SRFI-26 to Nix activation gexp.
From: |
Tobias Geerinckx-Rice |
Subject: |
Re: 01/01: services: Add SRFI-26 to Nix activation gexp. |
Date: |
Wed, 12 Jun 2019 18:08:20 +0200 |
Ludo',
Ludovic Courtès wrote:
(srfi srfi-26) must not be added to the imported modules: it
would
import it from the host Guile, but the host Guile version may
differ
between users
I looked at ‘G-Expressions’ in the manual before but I didn't see
this documented. Did I miss it, or is this tribal knowledge?
Assuming there's at least a probably-good and definitely-bad set
of modules that should(n't) be imported this way: can we at least
print a warning when a non-(guix) module is listed, or whatever
the rule would be?
, and thus the resulting derivation would also differ.
Just to make sure I follow, it's obviously wrong it both cases:
this would only be exposed if Guile's CUT suddenly changed its
*behaviour* in a visible (and likely very unintentional) way,
right? Or does with-imported-modules pull in (and hash) the
actual object code (/closure)?
The right thing is to just (use-modules (srfi srfi-26)), which
has the
effect of using that module from the Guile being used for
builds.
Could you adjust it accordingly?
Please take a second to check whether 79d19d7d does what you
meant.
Thanks, and thanks for the bug fix!
Thank you for answering my many questions,
T G-R
signature.asc
Description: PGP signature