From: Ben Woodcroft <b.woodcroft@uq.edu.au>
To: "Leo Famulari" <leo@famulari.name>, "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: package dependencies
Date: Mon, 14 Dec 2015 17:37:59 +1000 [thread overview]
Message-ID: <566E71D7.6020103@uq.edu.au> (raw)
In-Reply-To: <20151214070332.GA13029@jasmine>
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.
next prev parent reply other threads:[~2015-12-14 7:38 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 [this message]
2015-12-14 8:56 ` Ludovic Courtès
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=566E71D7.6020103@uq.edu.au \
--to=b.woodcroft@uq.edu.au \
--cc=guix-devel@gnu.org \
--cc=leo@famulari.name \
--cc=ludo@gnu.org \
/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.