[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: package dependencies
From: |
Pjotr Prins |
Subject: |
Re: package dependencies |
Date: |
Mon, 14 Dec 2015 07:29:39 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Thanks Ludo. I still think it could be made a little clearer from the
packager's
perspective. How about concluding it with something like:
In short, to create a package, by default you should use 'inputs' for
dependencies. Use 'native-inputs' for tools used at build-time, but
not at runtime and use propagated-inputs when the other two do not
suffice.
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.
>
> HTH!
>
> Ludo’.
>
--
- [PATCH] doc: rephrase code of conduct., Alex Sassmannshausen, 2015/12/09
- Re: [PATCH] doc: rephrase code of conduct., Ludovic Courtès, 2015/12/09
- package dependencies, Fabian Harfert, 2015/12/09
- Re: package dependencies, Pjotr Prins, 2015/12/09
- Re: package dependencies, Ludovic Courtès, 2015/12/13
- Re: package dependencies,
Pjotr Prins <=
- Re: package dependencies, Ludovic Courtès, 2015/12/14
- Re: package dependencies, Pjotr Prins, 2015/12/14
- Re: package dependencies, Ludovic Courtès, 2015/12/14
- Re: package dependencies, Leo Famulari, 2015/12/14
- Re: package dependencies, Pjotr Prins, 2015/12/15
- Re: package dependencies, Ludovic Courtès, 2015/12/15
- Packagers tutorial, deployment tutorial, Pjotr Prins, 2015/12/15
- 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