Re: Building Guile with ‘-j1’?

["Ludovic Courtès" <ludo@gnu.org>]

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Mark H Weaver <mhw@netris.org> writes:
>
>> Hi Ludovic,
>>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> As the saying goes, “the cobbler’s children go barefoot”.  Guile/Guix
>>> are no exception since Guile builds are non-reproducible, despite work
>>> done a few years ago:
>>>
>>>   https://issues.guix.gnu.org/20272
>>>
>>> Until it’s fixed in Guile proper, what do you think of building Guile
>>> 2.0/2.2/3.0 with #:parallel-build? #f ?  We could do that in
>>> ‘core-updates’ now.

I pushed that as 2ea52f90141974fb5d88b8c6b1785817c4203da4.

> I'm not too found of it.  It'll make the already slow Guile build much
> slower, making the lower strata of core-updates packages more painfully
> slow to build and test.

Yes, it’s suboptimal.  OTOH, as I wrote, I think the slowdown is not as
important as one might think: a large fraction of the Guile build time
goes into building ice-9/eval.scm and the first few files, which is
already sequential (enforced by Guile’s makefile).

> It'll also enable us to overlook the issue for years to come
> (similarly to the fact that the testsuite of the Guix package itself
> hasn't been run in parallel for the last 6 years or so :-)).

It remains and bug to fix in Guile, no doubt.  But we also have to be
pragmatic IMO.

> It also won't fix the issue of Guix modules compiled in parallel
> suffering from the same problem.

Definitely.

> So I'd keep it as it is for now, as a reminder that this is a serious
> problem in need of a fix.

There’s also the problem that a fix in Guile takes time to deploy
(basically a ‘core-updates’ cycle).  It’s not the first time we work
around a Guile bug until it’s fixed in Guile proper.

Thanks,
Ludo’.