Okay, thanks. I'll use the second way then. I could also create a new file - jami-utils.scm and use it as a module, but a file containing only one procedure isn't good either.
On Tue, 10 Dec 2019 18:43:58 -0600 Caleb Ristvedt <caleb.ristv...@cune.org> wrote: > Jan Wielkiewicz <tona_kosmicznego_smie...@interia.pl> writes: > > > I tried both ways - the second works, but the first doesn't. > > That would be the "in theory, it would work" part. On further > investigation, source-module-closure has a #:select? keyword > argument, which takes a module name and returns #f if it shouldn't be > included in the closure. By default it's 'guix-module-name?', so it > only includes the guix modules, and not, for example, (gcrypt hash). > One might try passing #:select? (const #t), but this would likely > reveal further issues - for example, guile-gcrypt doesn't work > without libgcrypt, but source-module-closure isn't going to pull that > in. > > The short answer is "yeah, for big closures that reach outside of > guix (or especially that have non-scheme dependencies) > source-module-closure isn't perfect", and build-side code should try > to minimize the size of the closure it pulls in (which, for pretty > much any (gnu packages ...) module, is going to be huge). The second > solution is probably the better one here. > > There's this sort of awkward middle ground we don't see much where a > build-side procedure has to be specific to some relatively small set > of packages, but still to enough packages that repeating it in the > builder for each of those packages duplicates a lot of code. Splicing > the definition into the builder programmatically is a bit of a hack, > as it's still duplicated between each builder interned in the store, > but much better than copy+pasting manually. > > Hope that helps. > > - reepca Jan Wielkiewicz
