[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: package dependencies
From: |
Ludovic Courtès |
Subject: |
Re: package dependencies |
Date: |
Mon, 14 Dec 2015 09:56:29 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Leo Famulari <address@hidden> 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.
Thanks,
Ludo’.
diff --git a/doc/guix.texi b/doc/guix.texi
index 29cea5c..7b7e118 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -2305,9 +2305,16 @@ belong to (@pxref{package-cmd-propagated-inputs,
@command{guix
package}}, for information on how @command{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.
+For example this is necessary when a C/C++ library needs headers of
+another library to compile, or when a pkg-config file refers to another
+one @i{via} its @code{Requires} field.
+
+Another example where @code{propagated-inputs} is useful is for
+languages that lack a facility to record the run-time search path akin
+to ELF's @code{RUNPATH}; this includes Guile, Python, Perl, GHC, and
+more. To ensure that libraries written in those languages can find
+library code they depend on at run time, run-time dependencies must be
+listed in @code{propagated-inputs} rather than @code{inputs}.
@item @code{self-native-input?} (default: @code{#f})
This is a Boolean field telling whether the package should use itself as
- Re: Packagers tutorial, deployment tutorial, (continued)
- Re: Packagers tutorial, deployment tutorial, Ludovic Courtès, 2015/12/17
- Re: Packagers tutorial, deployment tutorial, Pjotr Prins, 2015/12/17
- Re: Packagers tutorial, deployment tutorial, Ludovic Courtès, 2015/12/17
- Re: Packagers tutorial, deployment tutorial, Christopher Allan Webber, 2015/12/17
- Re: Packagers tutorial, deployment tutorial, Leo Famulari, 2015/12/17
- Re: Packagers tutorial, deployment tutorial, Christopher Allan Webber, 2015/12/17
- Re: Packagers tutorial, deployment tutorial, Pjotr Prins, 2015/12/17
- Re: Packagers tutorial, deployment tutorial, Christopher Allan Webber, 2015/12/18
- Re: package dependencies, Leo Famulari, 2015/12/14
- Re: package dependencies, Ben Woodcroft, 2015/12/14
- Re: package dependencies,
Ludovic Courtès <=
- Re: package dependencies, Ludovic Courtès, 2015/12/15