bug#47221: Guile not in native-inputs when it should

[Maxime Devos]

Hi Guix,

(In response to bug#47027, but opened as a new bug.)

On Wed, 2021-03-17 at 21:52 +0100, Ludovic Courtès wrote:
> Hi,
> 
> Maxime Devos <maximedevos@telenet.be> skribis:
> [...]
> > Shouldn't the "guile" input be included in the native-inputs
> > as well (perhaps only native-inputs suffices), for cross-compilation?
> 
> Yes it should, good point.

FWIW, I tried to write a linter to catch these kind of issues.
(If there's a "guile" input, then there usually should also be
a "guile" native-input.)  Currently, it has too many false positives
for my taste.  I most likely won't be working on it in the near future
though.  (Preliminary patch attached)

> ./pre-int-env guix lint -t "check-inputs-should-also-be-native"

(Output attached)

Some suspicious things:
* guile-config & others are missing a "guile" in the native-inputs
* clipmenu & others use "wrap-script" to define wrapper scripts
  (in this case "guile" does not have to be in native-inputs).
  The "wrap-script" procedure from (guix build utils) uses the
  "which" procedure to determine where guile is located ...
  but this is incorrect when cross-compiling!

  (It is possible to override the "guile" binary used with a
  keyword argument).

  (I assume inputs in "inputs" do not contribute to the $PATH
  in a cross-compilation environment; only "native-inputs" should
  contribute to $PATH)

  idk if it is feasible or if there are complications, but
  IMHO the inputs in "inputs" shouldn't contribute to $PATH
  at all (not even when not cross-compilation), only inputs
  in $PATH.

There seems to be plenty of low-hanging cross-compilation fruit here!

Greetings,
Maxime

0001-lint-Check-whether-guile-should-be-in-native-inputs.patch
Description: Text Data

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