unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Jan Nieuwenhuizen <janneke@gnu.org>
To: Marius Bakke <mbakke@fastmail.com>
Cc: 40698-done@debbugs.gnu.org
Subject: bug#40698: [core-updates]: [PATCH v2] gnu: perl: Actually produce a host perl when cross-compiling.
Date: Mon, 20 Apr 2020 07:38:57 +0200	[thread overview]
Message-ID: <87eesisolq.fsf@gnu.org> (raw)
In-Reply-To: <87imhvh7fh.fsf@devup.no> (Marius Bakke's message of "Sun, 19 Apr 2020 16:33:06 +0200")

Marius Bakke writes:

Hello Marius,

>> Using this, I can cross-build perl and which allows me to ceate patches
>> to cross build, autoconf and automake that work to configure Guix git on
>> the Hurd.
>
> Wooow, awesome work (as usual)!
>
> Some feedback on the patch:

Wow, thanks!

>> -                (which "pwd")))
>> +                (which "pwd"))) ;TODO: fix cross-compile next rebuild cycle
>
> It might be clearer to add "TODO: use coreutils from INPUTS instead of
> 'which'" here, maybe mentioning the related substitution below.

Yes, changed now to

             ;; Use the right path for `pwd'.
             ;; TODO: use coreutils from INPUTS instead of 'which'
             ;; in next rebuild cycle, see fixup below.
             (substitute* "dist/PathTools/Cwd.pm"
               (("/bin/pwd")
                (which "pwd")))


>> +                     (let ((cross-checkout (assoc-ref %build-inputs "perl-cross")))
>> +                       (invoke "chmod" "-R" "+w" ".")
>
> Please use 'make-file-writable' instead of chmod.

Finally changed it to

                       (rename-file "Artistic" "Artistic.perl")
                       (rename-file "Copying" "Copying.perl")

>> +                       (copy-recursively cross-checkout "."))
>> +                     (let ((bash (assoc-ref %build-inputs "bash")))
>
> Use the scoped 'inputs' instead of the magical %build-inputs.

Ah, right!  There is the scoped `native-inputs' too.  I have always
missed that and been using %build-inputs instead.  Hmm.

>> +                       (substitute* '("ext/Errno/Errno_pm.PL")
>> +                         (( "\\$cpp < errno.c") "gcc -E errno.c")))
>
> Should $cpp not be replaced with 'g++'?

No, I don't think so.  The non-replaced value of $cpp is "gcc -E -P -", and
that breaks terribly; this substitution is only to remove -the `-P' and
input redirection.  I did change this to the somewhat nicer

                       (substitute* '("ext/Errno/Errno_pm.PL")
                         (("\\$cpp < errno.c") "$Config{cc} -E errno.c")))

and mentioned this with my patch sent to `perl-cross'.

>> +                     #t))
>> +                 (replace 'configure
...
>> +                         (("/gnu/store/[^/]*-bash-[^/]*") bash))
>
> This phase should add a let binding for (%store-directory) and refer to
> that instead of the literal /gnu/store strings (see e.g. 'git').

Ah...nice!  Done.

>> +                       (substitute* '("config.h")
>> +                         (("^#define OSNAME .*")
>> +                          (string-append "#define OSNAME \""
>> +                                         ,(if (hurd-target?) "GNU" "Linux")
>
> Would it make sense to upstream this?

Yes, I think so.  I created a patch, now added as `perl-cross.patch' too
and sent it upstream.

>> +                                         "\"\n"))
>> +                         (("^# HAS_NANOSLEEP") "/* #undef HAS_NANOSLEEP */")
>
> Is this substitution required on all cross-compilation targets?

Good question.  This is no longer necessary now that configure actually
detects the Hurd using gcc; togeether with my patch.

>> +                     ;; `make install' wants to install this; it wasn't built...
>> +                     (mkdir-p "cpan/Pod-Usage/blib/script")
>> +                     (with-output-to-file "cpan/Pod-Usage/blib/script/pod2text"
>> +                       (lambda _ (display "")))
>> +                     (with-output-to-file "cpan/Pod-Usage/blib/script/pod2usage"
>> +                       (lambda _ (display "")))
>> +                     (with-output-to-file "cpan/Pod-Checker/blib/script/podchecker"
>> +                       (lambda _ (display "")))
>> +                     (mkdir-p "cpan/Pod-Parser/blib/script")
>> +                     (with-output-to-file "cpan/Pod-Parser/blib/script/podselect"
>> +                       (lambda _ (display "")))
>
> Using '(call-with-output-file "foo" (const #t))' is clearer IMO.  Also
> consider using 'for-each' here.

Changed to

                     (with-directory-excursion "cpan"
                       (mkdir-p "Pod-Usage/blib/script")
                       (mkdir-p "Pod-Parser/blib/script")
                       (for-each (lambda (file)
                                   (call-with-output-file file
                                     (lambda (port) (display "" port))))
                                 '("Pod-Usage/blib/script/pod2text"
                                   "Pod-Usage/blib/script/pod2usage"
                                   "Pod-Checker/blib/script/podchecker"
                                   "Pod-Parser/blib/script/podselect")))

> Phew!  Thanks a lot for this, LGTM!

With these changes, pushed to core-updates as eaff60b35fed75c60d0db76c589e17d1500f60dd

Thanks a lot for your review, I was pretty certain that I missed some
things; but there were more things that I learned than I expected.
Also, a good question here and there is really helpful for me to improve
things or to do the right thing.

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

      reply	other threads:[~2020-04-20  5:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-18 16:31 [bug#40698] [core-updates]: [PATCH] gnu: perl: Actually produce a host perl when cross-compiling Jan Nieuwenhuizen
2020-04-19  8:54 ` [bug#40698] [core-updates]: [PATCH v2] " Jan Nieuwenhuizen
2020-04-19 14:33   ` Marius Bakke
2020-04-20  5:38     ` Jan Nieuwenhuizen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87eesisolq.fsf@gnu.org \
    --to=janneke@gnu.org \
    --cc=40698-done@debbugs.gnu.org \
    --cc=mbakke@fastmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).