taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:
> It used to take ~18 minutes on my machine, now less than 3. Sounds compelling. :-) > From fd5d9bf77fd38fad354d66c31e57bc9bbc86481f Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?= > <taylanbayi...@gmail.com> > Date: Thu, 5 Nov 2015 16:21:48 +0100 > Subject: [PATCH] build: pull: Compile .scm files in one process. > > * guix/build/pull.scm (call-with-process): Removed procedure. > (report-build-progress): Removed procedure. > (p-for-each): Removed procedure. > (build-guix): Don't create subprocesses to compile the .scm files. [...] > - ;; Build guix/*.scm before gnu/*.scm to speed > - ;; things up. > - (sort (find-files out "\\.scm") > - (let ((guix (string-append out "/guix")) > - (gnu (string-append out "/gnu"))) > - (lambda (a b) > - (or (and (string-prefix? guix a) > - (string-prefix? gnu b)) > - (string<? a b)))))))) This logic should be kept (with this version of the patch, it starts compiling gnu.scm, which depends on many modules, so the progress report stays at 0% for maybe 30s and then suddenly reaches 20%.) > + ;; Compile the .scm files. Also load every compiled file after writing > it > + ;; to work around <http://bugs.gnu.org/15602> (FIXME). > + (let* ((files (filter (cut string-suffix? ".scm" <>) > + (find-files out "\\.scm"))) > + (total (length files))) > + (let loop ((file (car files)) > + (files (cdr files)) > + (completed 0)) > + (display #\cr log-port) > + (format log-port "compiling...\t~5,1f% of ~d files" ;FIXME: i18n > + (* 100. (/ completed total)) total) > + (force-output log-port) > + (let ((go (string-append (string-drop-right file 4) > + ".go"))) > + (format debug-port "~%compiling '~a'...~%" file) > + (parameterize ((current-warning-port debug-port)) > + (compile-file file > + #:output-file go > + #:opts > + %auto-compilation-options) > + (load-compiled go))) So this simple ‘load-compiled’ call addresses <http://bugs.gnu.org/15602>, right? This is where the comment and explanation about this bug should go. The ‘load-compiled’ code seems to be the only difference with 52af657a, which was right before we noticed #15602 (which led to 178f77b2.) Another stylistic issue: please use ‘match’ instead of the unnameable primitives. ;-) Could you send an updated patch? Thanks! Ludo’.
