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
