From: Leo Prikler <firstname.lastname@example.org> To: Maxime Devos <email@example.com> Cc: firstname.lastname@example.org Subject: Re: Question: wrap-program without #:sh can be ok even when cross-compiling? Date: Sun, 06 Jun 2021 12:57:49 +0200 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> Am Sonntag, den 06.06.2021, 12:14 +0200 schrieb Maxime Devos: > Leo Prikler schreef op zo 06-06-2021 om 09:39 [+0200]: > > I think we might want to export a utility procedure > > (patch-shebangs files inputs) > > This procedure already exists, but is undocumented and > unexported. It is in (guix build gnu-build-system). > > (define* (patch-shebangs #:key inputs outputs (patch-shebangs? #t) > #:allow-other-keys) > [...]) This patch-shebangs doesn't take a list of files as arguments, it instead just iterates over all the files. I don't think this is particularly helpful in a cross-compiling context, where you want some files (most notably scripts, that don't get wrapped) to have its shebang drawn from inputs rather than native-inputs. You could use the patch-shebang primitive from (guix build utils), but you'd have to wrap it in something like (let ((path (search-path-as-list '("bin" "sbin") (map cdr INPUTS)))) (for-each (cute patch-shebang <> path) (find-files ...))) where INPUTS are inputs or native-inputs, whichever you want. Not very friendly imo. > > so that files used during build (e.g. configure, Makefile, etc.) > > can do > > (patch-shebangs build-stuff native-inputs) and the rest implicitly > > gets > > (patch-shebangs files inputs) during the patch-shebangs > > phase. WDYT? > > Looking at %standard-phases, we have > > (define %standard-phases > ;; Standard build phases, as a list of symbol/procedure pairs. > [...] > (phases [...] unpack bootstrap patch-usr-bin-file > patch-source-shebangs configure patch-generated-file- > shebangs > build check install > patch-shebangs [...])) > > Here, patch-source-shebangs calls patch-shebang for every file > in the source code. As #:path is not set, $PATH is used. Thus, > when cross-compiling, native-inputs (+ some implicit inputs) is used, > and when compiling natively, the union of native-inputs and inputs (+ > some implicit inputs) is used (*). > > Thus, the files used during build (configure, Makefile, ...) already > get a ‘good’ interpreter. (Unless I'm mistaken, I didn't test this.) I agree, that's the status quo. We want that to be retained, but we also want our cross-compilation story to be better. Hence imo allowing to pass files, constructing path from inputs and exporting this procedure might make sense. > (*) I looked into separating 'native-inputs' and 'inputs' even when > compiling > natively but it turned out to be more complicated than first > expected. Fair enough, nobody expects you to do everything at once. Regards, Leo
next prev parent reply other threads:[~2021-06-06 10:58 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-06 7:39 Leo Prikler 2021-06-06 10:14 ` Maxime Devos 2021-06-06 10:57 ` Leo Prikler [this message] -- strict thread matches above, loose matches on Subject: below -- 2021-06-05 18:39 Maxime Devos
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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Question: wrap-program without #:sh can be ok even when cross-compiling?' \ /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
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 NNTP newsgroup(s).