Hi Maxim, Maxim Cournoyer <[email protected]> skribis:
> Mark H Weaver <[email protected]> writes: > >> Hi Ludovic, >> >> Ludovic Courtès <[email protected]> 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’.
