[Top][All Lists]

[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)


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_

          ‘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

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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]