Hi Jonathan, I wrote: > Unfortunately, not all of our package definitions respect the --cores > option. Our 'icecat' package does, but I can see now that our > 'icedove' package does _not_ respect it. It would be good to fix that.
Jonathan Brielmaier <[email protected]> replied: > @Mark: Yes, it would by nice to fix that. Do we make something special > in Icecat to achieve that? I couldn't find anything obvious on a first > view... There's nothing special in the IceCat package to achieve it. The relevant code is in the default 'build' phase from 'gnu-build-system', here: <https://git.sv.gnu.org/cgit/guix.git/tree/guix/build/gnu-build-system.scm?id=7382aa00b82860762bc326dec6b45f8cd2161327#n338> _ (define* (build #:key (make-flags '()) (parallel-build? #t) _________________ #:allow-other-keys) ___ (apply invoke "make" __________ `(,@(if parallel-build? __________________ `("-j" ,(number->string (parallel-job-count))) __________________ '()) ____________ ,@make-flags))) The problem is that the 'icedove' package has a custom 'build' phase that does not honor (parallel-job-count). Ultimately, the relevant difference between the two packages is that the 'icecat' package uses the 'gnu-build-system' approach of running "./configure", "make" and "make install", whereas the 'icedove' package uses the (Mozilla-preferred) approach of creating a ".mozconfig" file and running "./mach configure", "./mach build" and "./mach install". If I remember correctly (from when I looked at the process listings provided in this bug report), "./mach build" seems to be passing a "-j<N>" argument to "make", but at present we have no control over the <N> is. The best solution would be to find a way to tell "./mach build" to pass a specific value of <N>. Ideally, <N> should be (parallel-job-count) if 'parallel-build?' is #t, otherwise it should be 1. What do you think? Thanks, Mark -- Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
