l...@gnu.org (Ludovic Courtès) skribis:
> Leo Famulari <l...@famulari.name> skribis:
>
>> 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.
>
> Good point. How about the patch below? I’m not sure whether/how to
> cross-reference from ‘python-build-system’ & co. since they don’t
> mention the problem.
Pushed as e0508b6.
Ludo’.
