unofficial mirror of 
 help / color / mirror / Atom feed
* Question: wrap-program without #:sh can be ok even when cross-compiling?
@ 2021-06-06  7:39 Leo Prikler
  2021-06-06 10:14 ` Maxime Devos
  0 siblings, 1 reply; 4+ messages in thread
From: Leo Prikler @ 2021-06-06  7:39 UTC (permalink / raw)
  To: maximedevos; +Cc: guix-devel

I think we might want to export a utility procedure
    (patch-shebangs files inputs)
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?

^ permalink raw reply	[flat|nested] 4+ messages in thread
* Question: wrap-program without #:sh can be ok even when cross-compiling?
@ 2021-06-05 18:39 Maxime Devos
  0 siblings, 0 replies; 4+ messages in thread
From: Maxime Devos @ 2021-06-05 18:39 UTC (permalink / raw)
  To: guix-devel

[-- Attachment #1: Type: text/plain, Size: 2777 bytes --]

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



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-06-06 10:58 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-06  7:39 Question: wrap-program without #:sh can be ok even when cross-compiling? Leo Prikler
2021-06-06 10:14 ` Maxime Devos
2021-06-06 10:57   ` Leo Prikler
  -- strict thread matches above, loose matches on Subject: below --
2021-06-05 18:39 Maxime Devos

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