So, those descriptions are right?Pjotr Prins <pjotr.public12@thebird.nl> skribis:This contains the most lucid description of 'inputs' I have yet seen. Could they go into the main Guix documentation?What do you think needs to be changed compared to the text at <http://www.gnu.org/software/guix/manual/html_node/package-Reference.html>?
That paragraph doesn't tell me much about what inputs actually are in any detail, only the semantics of how to specify them.
inputs
(default:'()
)Package or derivation inputs to the build. This is a list of lists, where each list has the name of the input (a string) as its first element, a package or derivation object as its second element, and optionally the name of the output of the package or derivation that should be used, which defaults to
"out"
.
I guess it is initially confusing why propagated-inputs exist as a concept - I presumed that inputs were "installed" too (an input of my input is my input). "force-install" is a bit ambiguous - force installed in the profile? in the store? What is "forced" - isn't every input required? What is the meaning of "install" exactly?propagated-inputs
(default:'()
)
This field is like
inputs
, but the specified packages will be force-installed alongside the package they belong to (seeguix package
, for information on howguix package
deals with propagated inputs.)
So I'm guessing this is supposed to mean that if library (A) needs headers of another library (B) when trying to compile (C) which requires (A), then library B should be in the propagated-inputs list of library A? This doesn't seem to have anything to do with being force installed. Also, an example from an interpreted language would be useful. Particularly since there seems to be some discussion about this on the mailing list atm.
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.
This makes the most sense out of the three input types to me, although again the second sentence doesn't follow logically from the first (to me). Also the second sentence might include a nod to testing e.g. this would be where packages required only for testing are specified. Also unclear what mistakes lint is picking up here (how can lint know what is being used at runtime?), and thus the reference to lint seems of little benefit (authors should always run lint, so what's the point of mentioning it here?).native-inputs
(default:'()
)
This field is like
inputs
, but in case of a cross-compilation it will be ensured that packages for the architecture of the build machine are present, such that executables from them can be used during the build.This 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 (see Invoking guix lint).