Re: cross-compiling in core-updates

[Sergei Trofimovich <slyfox@inbox.ru>]

[-- Attachment #1: Type: text/plain, Size: 5793 bytes --]

On Tue, 02 May 2017 09:14:21 +0200
Andy Wingo <wingo@igalia.com> wrote:

> On Fri 28 Apr 2017 21:04, Manolis Ragkousis <manolis837@gmail.com> writes:
> 
> > The reason for the cascading errors is bash-minimal.
> >
> > Trying to build `./pre-inst-env guix build bash-minimal'
> > on core-updates ends up with :
> >
> > The following derivation will be built:
> >    /gnu/store/1r0fpfcik796g2b5v9ns163sgan1rkmz-bash-minimal-4.4.12.drv
> > @ build-started
> > /gnu/store/1r0fpfcik796g2b5v9ns163sgan1rkmz-bash-minimal-4.4.12.drv -
> > x86_64-linux
> > /usr/local/var/log/guix/drvs/1r//0fpfcik796g2b5v9ns163sgan1rkmz-bash-minimal-4.4.12.drv.bz2
> > ice-9/psyntax.scm:1534:32: In procedure expand-macro:
> > ice-9/psyntax.scm:1534:32: Syntax error:
> > /gnu/store/k84sww1zzh33a5hw8bcmsa5yp7w628a8-bash-minimal-4.4.12-guile-builder:1:2285:
> > source expression failed to match any pattern in form (%modify-phases
> > phases* (delete (quote move-development-files)))
> > builder for
> > `/gnu/store/1r0fpfcik796g2b5v9ns163sgan1rkmz-bash-minimal-4.4.12.drv'
> > failed with exit code 1
> > @ build-failed
> > /gnu/store/1r0fpfcik796g2b5v9ns163sgan1rkmz-bash-minimal-4.4.12.drv - 1
> > builder for
> > `/gnu/store/1r0fpfcik796g2b5v9ns163sgan1rkmz-bash-minimal-4.4.12.drv'
> > failed with exit code 1
> > guix build: error: build failed: build of
> > `/gnu/store/1r0fpfcik796g2b5v9ns163sgan1rkmz-bash-minimal-4.4.12.drv' failed
> >
> > It's the same issue Sergei reported and commit 78dea6f1d4a did not fix it.  
> 
> Hi!
> 
> I suspect I know what this is.  First, the package in question:
> 
>   (define-public bash-minimal
>     ;; A stripped-down Bash for non-interactive use.
>     (package (inherit bash)
>       (name "bash-minimal")
>       (inputs '())                                ; no readline, no curses
> 
>       ;; No "include" output because there's no support for loadable modules.
>       (outputs (delete "include" (package-outputs bash)))
> 
>       (arguments
>        (let ((args `(#:modules ((guix build gnu-build-system)
>                                 (guix build utils)
>                                 (srfi srfi-1)
>                                 (srfi srfi-26))
>                      ,@(package-arguments bash))))
>          (substitute-keyword-arguments args
>            ((#:configure-flags flags)
>             `(list "--without-bash-malloc"
>                    "--disable-readline"
>                    "--disable-history"
>                    "--disable-help-builtin"
>                    "--disable-progcomp"
>                    "--disable-net-redirections"
>                    "--disable-nls"
> 
>                    ;; Pretend 'dlopen' is missing so we don't build loadable
>                    ;; modules and related code.
>                    "ac_cv_func_dlopen=no"
> 
>                    ,@(if (%current-target-system)
>                          '("bash_cv_job_control_missing=no"
>                            "bash_cv_getcwd_malloc=yes")
>                          '())))
>            ((#:phases phases)
>             `(modify-phases ,phases
>                ;; No loadable modules.
>                (delete 'move-development-files))))))))
> 
> So you are aware of the change in Guile regarding "keyword" matching in
> macros.  In this case the "delete" in the modify-phases macro is a
> keyword.  Whereas before in Guile, they were only matched by name, now
> they are matched by binding.  If the keyword was bound where the macro
> was defined, then it will only be matched to identifiers bound to the
> same variable when the macro is used.  Otherwise if the keyword was
> unbound when the macro was defined, then it will match by name, but only
> if the name is also unbound at the macro use.
> 
> In (guix build utils), `delete' is bound to "delete" from (srfi srfi-1).
> In the bash package definition, I am not sure what the scope is because
> it's staged.  However let's assume that the #:modules bit intends to
> make it so that srfi-1 is present also in the bash-minimal module.  That
> should work, right?  Except I think because the bash package *also*
> defines a #:modules argument, that will result in:
> 
>   #:modules the-bash-minimal-modules ... #:modules the-bash-modules
> 
> and the last keyword wins.  So, perhaps try putting the
> ,@(package-arguments bash) first in this list?
> 
>                     (#:modules ((guix build gnu-build-system)
>                                 (guix build utils)
>                                 (srfi srfi-1)
>                                 (srfi srfi-26))
>                      ,@(package-arguments bash))

Yay! The following patch makes bash-minimal compile fine!

diff --git a/gnu/packages/bash.scm b/gnu/packages/bash.scm
index ef22728a9..38aa1786e 100644
--- a/gnu/packages/bash.scm
+++ b/gnu/packages/bash.scm
@@ -213,7 +213,7 @@ without modification.")
     (arguments
-     (let ((args `(#:modules ((guix build gnu-build-system)
+     (let ((args `(,@(package-arguments bash)
+                   #:modules ((guix build gnu-build-system)
                               (guix build utils)
                               (srfi srfi-1)
-                              (srfi srfi-26))
-                   ,@(package-arguments bash))))
+                              (srfi srfi-26)))))
        (substitute-keyword-arguments args

I'm afraid I understood almost nothing about your comments of 
visibility. The only thing I've got is that keyword argument order
matters :)

Would the similar ordering change have the no-op effect in master
branch or does it mean core-updates should do this reordering while
master should not?

Thank you!

-- 

  Sergei

[-- Attachment #2: Цифровая подпись OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]