Re: package dependencies

[Ben Woodcroft <b.woodcroft@uq.edu.au>]

On 14/12/15 17:03, Leo Famulari wrote:
> 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.
+1. And perhaps making reference to scripting languages in general too.