Taylan Ulrich Kammer <taylanbayi...@gmail.com> skribis:
> From 0f001497234df55e3c131c10f84ddf184261ee09 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
> <taylanbayi...@gmail.com>
> Date: Thu, 14 May 2015 22:37:04 +0200
> Subject: [PATCH] doc: Document native-inputs and propagated-inputs.
>
> * doc/guix.texi (Defining Packages): Add `native-inputs' and
> `propagated-inputs' fields to the example package recipe, and explain them.
[...]
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -1716,6 +1716,8 @@ package looks like this:
> (build-system gnu-build-system)
> (arguments `(#:configure-flags '("--enable-silent-rules")))
> (inputs `(("gawk" ,gawk)))
> + (native-inputs `(("pkg-config" ,pkg-config)))
> + (propagated-inputs `(("libfoo" ,libfoo)))
I would not add it here since it’s incorrect code.
> +@item
> +The @code{native inputs} field specifies inputs for which it should be
> +ensured that the version present at build-time is for the architecture
> +on which the build is running. This is necessary for cross-compilation
> +when programs from the input will be executed at build-time. This field
> +will frequently have build tools such as autotools components, libtool,
> +pkg-config, or gettext.
s/autotools components/Autoconf/ and capitalize “Libtool” and “Gettext.”
> +@item
> +The @code{propagated inputs} field specifies inputs whose installation
> +should be forced alongside the installation of the package. For
> +example, some shared libraries expect another shared library, on which
> +they depend, to be linked alongside them. In that case said dependency
> +should be installed alongside the library, so that when a program wants
> +to use the library it can correctly link against both the library and
> +its dependency.
What about taking the example that is in “Invoking guix package”, which
explicitly mentions C header file dependencies?
More importantly, I think we should have a “package Reference” section
(akin to the existing “operating-system Reference” section) right after
“Defining Packages.” That way, we could keep “Defining Packages” simple
and concise, and simply cross-ref to the reference section for details.
That’s more work, but that’d be real cool. WDYT? :-)
Thanks!
Ludo’.
