Re: Fixing non-reproducibility in some guile packages

[Andy Wingo <wingo@igalia.com>]

Hi :)

[+guile-devel]

On Mon 13 Feb 2017 07:18, Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

>>>      ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
>>>      ;;;       or pass the --no-auto-compile argument to disable.
>>>      ;;; compiling /gnu/store/d3gli8g5bv6yhd3qwk5rfzqpsfvnj4lv-guile-next-2.1.5/bin/guild
>
> I've notice this same problem recently while looking at the build-log of
> our GnuCash package.. It seems to be the problem is caused by the Guile
> wanting to auto-compile the guild script, and not being able to as it
> wants to store the compiled version somewhere under $HOME.
>
> Could a generally applicable solution be to distribute a pre-compiled
> guild.go in the store, so that it would use that and never attempt to
> 'auto-compile' it?  This would effectively fix this problem for good
> without having to create workaround such as using environment variables
> or setting HOME to a temp dir.

The compiled .go files that get installed are only for files found in
the Guile load path.  So like when you load (foo bar), it will look for
foo/bar.go in the %load-compiled-path (and foo/bar.scm in the
%load-path).  This lets you compile foo/bar.scm in your build directory
and have the resulting foo/bar.go in the builddir directly usable from
the build-time %load-path / %load-compiled-path, and to install you just
copy into the final %load-path / %load-compiled-path and that works too.

For scripts that are loaded by absolute file name (guild is a prominent
example) that don't live in the %load-path, this technique isn't
directly applicable.  The existing %load-compiled-path is effectively a
function from name-suffix (like "foo/bar.scm") to absolute path of
compiled .go file.  We would need an additional mechanism to be a
function from absolute source file name to absolute path of .go file.
Perhaps that's doable with an additional path.  Perhaps the fallback
compilation path (~/.cache/guile/...) could be generalized to include
something in $prefix also so that packages can install compiled files.
Incidentally probably we should SHA256 the path to prevent so much
directory traversal...

In some future (is it near or far?), the source -> compiled function
needs additional inputs: checksums or timestamps of "build inputs" or
so, so that when for-syntax definitions (like macros) change, users of
those definitions will recompile.  That is a harder problem though.

Andy