unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
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

  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

  List information: https://guix.gnu.org/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).