[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Design decision behind inputs/native-inputs/propagated-inputs
From: |
Ludovic Courtès |
Subject: |
Re: Design decision behind inputs/native-inputs/propagated-inputs |
Date: |
Thu, 21 Jan 2016 10:59:53 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Hello,
Steven Allen <address@hidden> skribis:
> I just attended David Thompson's talk about Guix and asked some
Cool, glad that it led you to contact us! ;-)
> Currently, I use Arch. On Arch, we have makedepends and depends where
> only depends are kept at runtime. On Guix, this distinction is detected
> at build time by searching the output files for references into the
> inputs. However, unless I'm mistaken, native-inputs are *usually* build
> dependencies and inputs are *usually* runtime dependencies. So, my
> question is why not:
>
> 1. Get rid of the automagic run/build dependency detection.
> 2. Have:
> a. private-inputs -- runtime dependencies not linked into the environment
> b. propagated-inputs -- no change
> c. build-inputs -- always native, never included in the final output
>
> Specifically, what is the use case for non-native build-only dependencies
> (inputs that are not included in the final package) and native runtime
> dependencies (native-inputs that *are* included in the final package)?
> Alternatively, am I completely missing the point?
The description of these three things has been improved in the manual on
‘master’, compared to what’s on the on-line manual:
--8<---------------cut here---------------start------------->8---
‘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 C/C++ library needs
headers of another library to compile, or when a pkg-config
file refers to another one via its ‘Requires’ field.
Another example where ‘propagated-inputs’ is useful is for
languages that lack a facility to record the run-time search
path akin to ELF’s ‘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
‘propagated-inputs’ rather than ‘inputs’.
--8<---------------cut here---------------end--------------->8---
In short, the distinction between ‘native-inputs’ and ‘inputs’ exists
solely because Guix supports cross-compilation. Otherwise it would be
unneeded.
Propagated inputs are a way to manually say: “I want this package to
automatically pull in those other packages.” This is necessary in the
cases given above.
Does this clarify the rationale?
Thanks for your feedback,
Ludo’.
- Design decision behind inputs/native-inputs/propagated-inputs, Steven Allen, 2016/01/21
- Re: Design decision behind inputs/native-inputs/propagated-inputs,
Ludovic Courtès <=
- Re: Design decision behind inputs/native-inputs/propagated-inputs, Steven Allen, 2016/01/21
- Re: Design decision behind inputs/native-inputs/propagated-inputs, Ben Woodcroft, 2016/01/21
- Message not available
- Message not available
- Re: Design decision behind inputs/native-inputs/propagated-inputs, Steven Allen, 2016/01/21
- Re: Design decision behind inputs/native-inputs/propagated-inputs, Ben Woodcroft, 2016/01/21
- Re: Design decision behind inputs/native-inputs/propagated-inputs, Steven Allen, 2016/01/21
- Re: Design decision behind inputs/native-inputs/propagated-inputs, Steven Allen, 2016/01/23
- Re: Design decision behind inputs/native-inputs/propagated-inputs, Ludovic Courtès, 2016/01/23
- Re: Design decision behind inputs/native-inputs/propagated-inputs, Steven Allen, 2016/01/23