From: ludo@gnu.org (Ludovic Courtès)
To: Leo Famulari <leo@famulari.name>
Cc: guix-devel@gnu.org
Subject: Re: package dependencies
Date: Mon, 14 Dec 2015 09:56:29 +0100 [thread overview]
Message-ID: <87h9jlz9vm.fsf@gnu.org> (raw)
In-Reply-To: <20151214070332.GA13029@jasmine> (Leo Famulari's message of "Mon, 14 Dec 2015 02:03:32 -0500")
[-- Attachment #1: Type: text/plain, Size: 2840 bytes --]
Leo Famulari <leo@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.
Thanks,
Ludo’.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1207 bytes --]
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
next prev parent reply other threads:[~2015-12-14 8:56 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-09 17:29 [PATCH] doc: rephrase code of conduct Alex Sassmannshausen
2015-12-09 19:13 ` package dependencies Fabian Harfert
2015-12-10 4:55 ` Pjotr Prins
2015-12-13 13:45 ` Ludovic Courtès
2015-12-14 6:29 ` Pjotr Prins
2015-12-14 8:58 ` Ludovic Courtès
2015-12-14 9:28 ` Pjotr Prins
2015-12-14 16:47 ` Ludovic Courtès
2015-12-14 19:36 ` Leo Famulari
2015-12-15 10:18 ` Pjotr Prins
2015-12-15 10:57 ` Ludovic Courtès
2015-12-16 4:53 ` Packagers tutorial, deployment tutorial Pjotr Prins
2015-12-17 13:01 ` Ludovic Courtès
2015-12-17 18:40 ` Pjotr Prins
2015-12-17 22:09 ` Ludovic Courtès
2015-12-17 22:58 ` Christopher Allan Webber
2015-12-18 1:03 ` Leo Famulari
2015-12-18 1:40 ` Christopher Allan Webber
2015-12-18 3:53 ` Pjotr Prins
2015-12-18 16:58 ` Christopher Allan Webber
2015-12-14 7:03 ` package dependencies Leo Famulari
2015-12-14 7:37 ` Ben Woodcroft
2015-12-14 8:56 ` Ludovic Courtès [this message]
2015-12-15 12:57 ` Ludovic Courtès
2015-12-09 21:19 ` [PATCH] doc: rephrase code of conduct Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h9jlz9vm.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guix-devel@gnu.org \
--cc=leo@famulari.name \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.