Hello!
I’ve rephrased the doc in “package Reference” in a way that is hopefully
clearer:
‘inputs’ (default: ‘'()’)
‘native-inputs’ (default: ‘'()’)
‘propagated-inputs’ (default: ‘'()’)
These fields list dependencies of the package. Each one is a
list of tuples, where each tuple has a label for the input (a
string) as its first element, a package, origin, or derivation
as its second element, and optionally the name of the output
thereof that should be used, which defaults to ‘"out"’ (*note
Packages with Multiple Outputs::, for more on package
outputs). For example, the list below specifies 3 inputs:
`(("libffi" ,libffi)
("libunistring" ,libunistring)
("glib:bin" ,glib "bin")) ;the "bin" output of Glib
The distinction between ‘native-inputs’ and ‘inputs’ is
necessary when considering cross-compilation. When
cross-compiling, dependencies listed in ‘inputs’ are built for
the _target_ architecture; conversely, dependencies listed in
‘native-inputs’ are built for the architecture of the _build_
machine.
‘native-inputs’ is typically where you would list tools needed
at build time but not at run time, such as Autoconf, Automake,
pkg-config, Gettext, or Bison. ‘guix lint’ can report likely
mistakes in this area (*note Invoking guix lint::).
Lastly, ‘propagated-inputs’ is similar to ‘inputs’, but the
specified packages will be force-installed alongside the
package they belong to (*note ‘guix package’:
package-cmd-propagated-inputs, for information on how ‘guix
package’ deals with propagated inputs.)
For example this is necessary when a library needs headers of
another library to compile, or needs another shared library to
be linked alongside itself when a program wants to link to it.
HTH!
Ludo’.
