Re: package dependencies

[Leo Famulari <leo@famulari.name>]

On Sun, Dec 13, 2015 at 02:45:46PM +0100, Ludovic Courtès wrote:
> 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.

I think it's a good improvement! This is a big obstacle for new
packagers.

It may be worth linking between the sections about propagated-inputs and
the python-build-system, since the situation is somewhat different
there. At least in a footnote.

> 
> HTH!
> 
> Ludo’.
>