[Top][All Lists]

[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 <>
(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 ...


to ...


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

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
    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 
    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.



Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]