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
prev parent 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).