[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Question: wrap-program without #:sh can be ok even when cross-compiling?
From: |
Maxime Devos |
Subject: |
Question: wrap-program without #:sh can be ok even when cross-compiling? |
Date: |
Sat, 05 Jun 2021 20:39:10 +0200 |
User-agent: |
Evolution 3.34.2 |
About <https://issues.guix.gnu.org/47869>
(the ‘wrap-program #:sh’ patch series):
While looking at guix/build/gnu-build-system.scm,
I noticed the 'patch-shebangs' phase, which is run
after the install phase. IIUC, this phase is for
changing shebangs ...
#!/usr/bin/stuff
to ...
#!/gnu/store/...-stuff-1.0/bin/stuff
IIUC, this phase tries to find the interpreter
in 'inputs'. So, if the original interpreter
was for SYSTEM, the new interpreter is for TARGET.
As such, when cross-compiling, when bash is present
in the inputs, when the patch-shebangs phase isn't
disabled and we use wrap-program without a #:sh
argument, even though wrap-program will use an
interpreter for SYSTEM, the patch-shebangs will
automatically correct it for us to an interpreter
for TARGET.
So, is the patch series in bug#47869 still useful?
* if, for some reason, patch-shebangs? is #f,
then we need to explicitely #:sh set --> patch useful
patch-shebangs? doesn't seem to be set to #f anywhere though.
* some build systems might not have a patch-shebangs phase
(I'm not aware of any such build systems though) --> patch useful
* explicit is better than implicit [citation needed, see e.g. python]
--> patch useful
The extra verbosity seems acceptable in build systems
(see e.g. usage of wrap-program in
guix/build/glib-or-gtk-build-system.scm
and guix/build/python-build-system.scm).
Dunno about package definitions though.
So I'd would say yes! But should we explicitely set
#:sh (search-input-file inputs "bin/bash")
in package definitions?
Cons for explicit / pros for implicit (relying on patch-shebangs):
* explicit form is a bit verbose
* in the transition, many, many package definitions need to be adjusted.
Pros for explicit / cons for explicit:
* by explicitely writing #:sh (search-input-file inputs "bin/bash"),
it should be clear that bash-minimal (or bash) needs to be added
to the package inputs
(Note that I intend to separate 'inputs' from 'native-inputs' in
build phases even when compiling natively. Haven't gotten around to
trying it though, seems complicated ...)
Alternative: write a linter checking that wrap-program is only used
if "bash" (or "bash-minimal") is in the package inputs (native-inputs
doesn't count here).
* Using the explicit form is always correct. The implicit #:sh (which
"bin/bash")
is not always corrected by the patch-shebangs phase.
Note that when cross-compiling, not setting #:sh and when bash
is absent from inputs, the patch-shebang phase merely emits a warning
(which can easily get lost in the noise) and _not_ an error.
Thoughts?
Maxime.
signature.asc
Description: This is a digitally signed message part
- Question: wrap-program without #:sh can be ok even when cross-compiling?,
Maxime Devos <=