Re: [PATCH] doc: Document native-inputs and propagated-inputs.

[ludo@gnu.org (Ludovic Courtès)]

Taylan Ulrich Kammer <taylanbayirli@gmail.com> skribis:

> From 0f001497234df55e3c131c10f84ddf184261ee09 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
>  <taylanbayirli@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’.