guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] build: pull: Compile .scm files in one process.


From: Ludovic Courtès
Subject: Re: [PATCH] build: pull: Compile .scm files in one process.
Date: Thu, 05 Nov 2015 22:06:43 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

address@hidden (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?=
>  <address@hidden>
> 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’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]