bug#27284: Memory leak in 'guix pull' or 'make' in guix source

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

ludo@gnu.org (Ludovic Courtès) writes:

> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>
> [...]
>
>> 2. Remove the --no-auto-compile arg from (guix scripts guix).
>>
>> I'm not sure why this is desirable. Is it because otherwise the cached
>> compiled copies would be susceptible to ABI breakages?
>
> Yes, that’s one thing.
>
> Another thing is that on the first run of ‘guix package’ following ‘guix
> pull’, you’d end up compiling everything, which is not much better than
> compiling them upfront.

To be clear, my suggestion of removing --no-auto-compile was not as a
replacement to compilation, but in addition to. Thinking more about what
I wrote yesterday, it seems what I had on mind was a custom, optimized
way to build Guix that would minimize the amount of files to recompile,
ala 'git pull && make' without running make clean-go or even ./configure
(under the condition that the closure of guix hasn't changed -- when it
does, a full rebuild would be necessary to ensure determinism).

As an unrelated note, I find --no-auto-compile annoying in a development
context when working directly from the guix tree. It forces you to
constantly run 'make', otherwise it recompiles modules changed since the
last 'make' every time Guile needs them, even when they haven't changed
on disk.

> There’s also the option of not compiling (gnu packages *) and instead
> evaluating them, but currently this is too costly in terms of memory and
> CPU.

How do we instruct Guile to evaluate rather than compile? I don't think
I've ever experimented with this yet!

Maxim