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

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

[Taylan Ulrich Kammer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: 0001-doc-Document-native-inputs-and-propagated-inputs.patch --]
[-- Type: text/x-diff, Size: 2247 bytes --]

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.
---
 doc/guix.texi | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index 049292d..1826b25 100644
--- 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)))
     (synopsis "Hello, GNU world: An example GNU package")
     (description "Guess what GNU Hello prints!")
     (home-page "http://www.gnu.org/software/hello/")
@@ -1791,6 +1793,23 @@ of ensuring that they are present (@pxref{Build Systems}).
 However, any other dependencies need to be specified in the
 @code{inputs} field.  Any dependency not specified here will simply be
 unavailable to the build process, possibly leading to a build failure.
+
+@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.
+
+@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.
 @end itemize
 
 Once a package definition is in place, the
-- 
2.2.1

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

[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’.

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

[Taylan Ulrich Bayırlı/Kammer]

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

ludo@gnu.org (Ludovic Courtès) writes:

> 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?  :-)

I had a go at it but could not immediately figure out the meanings of
some package and origin fields.  Help much appreciated. :-)

Patch so far:


[-- Attachment #2: 0001-doc-Add-package-Reference-and-origin-Reference-secti.patch --]
[-- Type: text/x-diff, Size: 7068 bytes --]

From 948fcdbb0cea1b8fcd7907554c61633db2f54dd8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
 <taylanbayirli@gmail.com>
Date: Fri, 15 May 2015 21:54:11 +0200
Subject: [PATCH] doc: Add "package Reference" and "origin Reference" sections.

* doc/guix.texi (Defining Packages): Link to "package Reference".  Add menu.
(package Reference, origin Reference): New subsections.
---
 doc/guix.texi | 161 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 161 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index 049292d..c91c910 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -1793,6 +1793,8 @@ However, any other dependencies need to be specified in the
 unavailable to the build process, possibly leading to a build failure.
 @end itemize
 
+See @pxref{package Reference} for a full description of possible fields.
+
 Once a package definition is in place, the
 package may actually be built using the @code{guix build} command-line
 tool (@pxref{Invoking guix build}).  @xref{Packaging Guidelines}, for
@@ -1837,6 +1839,165 @@ and operating system, such as @code{"mips64el-linux-gnu"}
 Configure and Build System}).
 @end deffn
 
+@menu
+* package Reference ::          The package data type.
+* origin Reference::            The origin data type.
+@end menu
+
+
+@node package Reference
+@subsection package Reference
+
+This section summarizes all the options available in ‘package’
+declarations (@pxref{Defining Packages}).
+
+@deftp {Data Type} package
+This is the data type representing a package recipe.
+
+@table @asis
+@item @code{name}
+The name of the package, as a string.
+
+@item @code{version}
+The version of the package, as a string.
+
+@item @code{source}
+An origin object (@pxref{origin Reference}) telling how the source
+code for the package should be acquired.
+
+@item @code{build-system}
+The build system (@pxref{Build Systems}) that should be used to
+build the package.
+
+@item @code{arguments} (default: @code{'()})
+The arguments that should be passed to the build system.  This is a
+list, typically containing sequential keyword-value pairs.
+
+@item @code{inputs} (default: @code{'()})
+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 @code{"out"}.
+
+@item @code{propagated-inputs} (default: @code{'()})
+This field is like @code{inputs}, but the specified packages will be
+force-installed alongside the package they belong to.  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.
+
+@item @code{native-inputs} (default: @code{'()})
+This field is like @code{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.  For example, this is necessary for build tools such as Autoconf,
+Libtool, pkg-config, or Gettext.
+
+@item @code{self-native-input?} (default: @code{#f})
+This is a Boolean field telling whether the package should use itself as
+a native input when cross-compiling.
+
+@item @code{outputs} (default: @code{'("out")})
+The list of output names of the package.
+
+@item @code{native-search-paths} (default: @code{'()})
+FIXME
+
+@item @code{search-paths} (default: @code{'()})
+FIXME
+
+@item @code{replacement} (default: @code{'()})
+FIXME
+
+@item @code{synopsis}
+A one-line description of the package.
+
+@item @code{description}
+A more elaborate description of the package.
+
+@item @code{license}
+The license of the package; a value from @code{(guix licenses)}.
+
+@item @code{home-page}
+The URL to the home-page of the package, as a string.
+
+@item @code{supported-systems} (default: @var{%supported-systems})
+The list of systems supported by the package, as strings of the form
+@code{architecture-kernel}, for example @code{"x86_64-linux"}.
+
+@item @code{maintainers} (default: @code{'()})
+The list of maintainers of the package.  FIXME: upstream, or package
+recipe?
+
+@item @code{properties} (default: @code{'()})
+An alist of arbitrary properties of the package.
+
+@item @code{location} (default: source location of the @code{package} form)
+The source location of the package.  It's useful to override this when
+inheriting from another package, in which case this field is not
+automatically corrected.
+@end table
+@end deftp
+
+
+@node origin Reference
+@subsection origin Reference
+
+This section summarizes all the options available in @code{origin}
+declarations (@pxref{Defining Packages}).
+
+@deftp {Data Type} origin
+This is the data type representing a source code origin.
+
+@table @asis
+@item @code{uri}
+A string containing the URI of the source.
+
+@item @code{method}
+A procedure that will handle the URI, such as @code{url-fetch}.
+
+@item @code{sha256}
+A bytevector containing the SHA-256 hash of the source.  Typically the
+@code{base32} procedure is used here to generate the bytevector from a
+base-32 string.
+
+@item @code{file-name} (default: @code{#f})
+The file name under which the source code should be saved.  When this is
+@code{#f}, a sensible default value will be used in most cases.  In case
+the source is fetched from a URL, the file name from the URL will be
+used.  For version control checkouts, it's recommended to provide the
+file name explicitly because the default is not very descriptive.
+
+@item @code{patches} (default: @code{'()})
+A list of file names containing patches to be applied to the source.
+
+@item @code{snippet} (default: @code{#f})
+A quoted piece of code that will be run in the source directory to make
+any modifications, which is sometimes more convenient than a patch.
+
+@item @code{patch-flags} (default: @code{'("-p1")})
+A list of command-line flags that should be passed to the @code{patch}
+command.
+
+@item @code{patch-inputs} (default: @code{#f})
+Input packages or derivations to the patching process.  When this is
+@code{#f}, the usual set of inputs necessary for patching are provided,
+such as GNU Patch.
+
+@item @code{modules} (default: @code{'()})
+A list of Guile modules that should be loaded during the patching
+process and while running the code in the @code{snippet} field.
+
+@item @code{imported-modules} (default: @code{'()})
+FIXME
+
+@item @code{patch-guile} (default: @code{#f})
+The Guile package that should be used in the patching process.  When
+this is @code{#f}, a sensible default is used.
+@end table
+@end deftp
+
 
 @node Build Systems
 @section Build Systems
-- 
2.2.1

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

[Ludovic Courtès]

taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:

> From 948fcdbb0cea1b8fcd7907554c61633db2f54dd8 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
>  <taylanbayirli@gmail.com>
> Date: Fri, 15 May 2015 21:54:11 +0200
> Subject: [PATCH] doc: Add "package Reference" and "origin Reference" sections.
>
> * doc/guix.texi (Defining Packages): Link to "package Reference".  Add menu.
> (package Reference, origin Reference): New subsections.

This looks great!

> +See @pxref{package Reference} for a full description of possible fields.

Should be:

  @xref{package Reference}, for a full description...

(@xref generates “See” and must be followed by a comma.)

> +@node package Reference
> +@subsection package Reference

@subsection @code{package} Reference

(Same for the second subsection.)

> +This section summarizes all the options available in ‘package’

@code{package}

> +@item @code{build-system}
> +The build system (@pxref{Build Systems}) that should be used to
> +build the package.

In general try to put parentheses at the end of the sentence so that
it’s easier to read.

> +@item @code{outputs} (default: @code{'("out")})
> +The list of output names of the package.

+ @xref{Packages with Multiple Outputs}, for typical uses of additional
outputs.

> +@item @code{native-search-paths} (default: @code{'()})
> +FIXME
> +
> +@item @code{search-paths} (default: @code{'()})
> +FIXME

You can group both with @itemx.  For now, let’s just say that it’s a
list of @code{search-path-specification} objects describing search-path
environment variables honored by the package.  We can write the
‘search-path-specification’ reference another day.  ;-)

> +@item @code{replacement} (default: @code{'()})
> +FIXME

Default is @code{#f}.
Something like:

  This must either @code{#f} or a package object that will be used as a
  @dfn{replacement} for this package.  @xref{Security Updates, grafts},
  for details.

> +@item @code{maintainers} (default: @code{'()})
> +The list of maintainers of the package.  FIXME: upstream, or package
> +recipe?

It’s still unused, but it’s meant to be the list of downstream package
maintainers, represented as a list of <maintainer> objects (imagine a
(guix maintainers) module akin to (guix licenses) where we would all
live.)  Probably now would be a good time to start discussing it.

> +@item @code{properties} (default: @code{'()})
> +An alist of arbitrary properties of the package.

Leave that one undocumented (it’s currently unused and I’m not sure it’s
useful.)


[...]

> +@deftp {Data Type} origin
> +This is the data type representing a source code origin.
> +
> +@table @asis
> +@item @code{uri}
> +A string containing the URI of the source.

s/A string/An object/

You can add:

  The object type depends on the @code{method} (see below.)  For
  example, when using the @var{url-fetch} method of @code{(guix
  download)}, the valid @code{uri} values are: a URL represented as a
  string, or a list thereof.

> +@item @code{method}
> +A procedure that will handle the URI, such as @code{url-fetch}.

s/,.*//

Add a paragraph:

  Examples include:

  @table @asis
  @item @var{url-fetch} from @code{(guix download)}
  download a file the HTTP, HTTPS, or FTP URL specified in the
  @code{uri} field;

  @item @var{git-fetch} from @code{(guix git-download)}
  clone the Git version control repository, and check out the revision
  specified in the @code{uri} field as a @code{git-reference} object; a
  @code{git-reference} looks like this:

  @example
  (git-reference
    (url "git://git.debian.org/git/pkg-shadow/shadow")
    (commit "v4.1.5.1"))
  @end example
  @end @table

> +@item @code{sha256}
> +A bytevector containing the SHA-256 hash of the source.  Typically the
> +@code{base32} procedure is used here to generate the bytevector from a

s/procedure/form/

> +@item @code{patch-inputs} (default: @code{#f})
> +Input packages or derivations to the patching process.  When this is
> +@code{#f}, the usual set of inputs necessary for patching are provided,
> +such as GNU Patch.

GNU@tie{}Patch

> +@item @code{imported-modules} (default: @code{'()})

The list of Guile modules to import in the patch derivation, for use by
the @code{snippet}.

Could you send an updated patch?

Excellent work, thank you!

Ludo’.

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

[Taylan Ulrich Bayırlı/Kammer]

[-- Attachment #1: Type: text/plain, Size: 337 bytes --]

ludo@gnu.org (Ludovic Courtès) writes:

>> +@item @code{imported-modules} (default: @code{'()})
>
> The list of Guile modules to import in the patch derivation, for use
> by the @code{snippet}.

I don't understand how this differs from `modules'?

> Could you send an updated patch?

Here it is.  Thanks for all the help!


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-doc-Add-package-Reference-and-origin-Reference-secti.patch --]
[-- Type: text/x-diff, Size: 7938 bytes --]

From 8e77504fef71b7679f52d257014a7d85a73a247a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
 <taylanbayirli@gmail.com>
Date: Fri, 15 May 2015 21:54:11 +0200
Subject: [PATCH] doc: Add "package Reference" and "origin Reference" sections.

* doc/guix.texi (Defining Packages): Link to "package Reference".  Add menu.
(package Reference, origin Reference): New subsections.
---
 doc/guix.texi | 182 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 182 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index 049292d..b3a31c7 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -1793,6 +1793,8 @@ However, any other dependencies need to be specified in the
 unavailable to the build process, possibly leading to a build failure.
 @end itemize
 
+@xref{package Reference}, for a full description of possible fields.
+
 Once a package definition is in place, the
 package may actually be built using the @code{guix build} command-line
 tool (@pxref{Invoking guix build}).  @xref{Packaging Guidelines}, for
@@ -1837,6 +1839,186 @@ and operating system, such as @code{"mips64el-linux-gnu"}
 Configure and Build System}).
 @end deffn
 
+@menu
+* package Reference ::          The package data type.
+* origin Reference::            The origin data type.
+@end menu
+
+
+@node package Reference
+@subsection @code{package} Reference
+
+This section summarizes all the options available in @code{package}
+declarations (@pxref{Defining Packages}).
+
+@deftp {Data Type} package
+This is the data type representing a package recipe.
+
+@table @asis
+@item @code{name}
+The name of the package, as a string.
+
+@item @code{version}
+The version of the package, as a string.
+
+@item @code{source}
+An origin object telling how the source code for the package should be
+acquired (@pxref{origin Reference}).
+
+@item @code{build-system}
+The build system that should be used to build the package (@pxref{Build
+Systems}).
+
+@item @code{arguments} (default: @code{'()})
+The arguments that should be passed to the build system.  This is a
+list, typically containing sequential keyword-value pairs.
+
+@item @code{inputs} (default: @code{'()})
+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 @code{"out"}.
+
+@item @code{propagated-inputs} (default: @code{'()})
+This field is like @code{inputs}, but the specified packages will be
+force-installed alongside the package they belong to.  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.
+
+@item @code{native-inputs} (default: @code{'()})
+This field is like @code{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.  For example, this is necessary for build tools such as Autoconf,
+Libtool, pkg-config, or Gettext.
+
+@item @code{self-native-input?} (default: @code{#f})
+This is a Boolean field telling whether the package should use itself as
+a native input when cross-compiling.
+
+@item @code{outputs} (default: @code{'("out")})
+The list of output names of the package.  @xref{Packages with Multiple
+Outputs}, for typical uses of additional outputs.
+
+@item @code{native-search-paths} (default: @code{'()})
+@itemx @code{search-paths} (default: @code{'()})
+A list of @code{search-path-specification} objects describing
+search-path environment variables honored by the package.
+
+@item @code{replacement} (default: @code{#f})
+This must either @code{#f} or a package object that will be used as a
+@dfn{replacement} for this package.  @xref{Security Updates, grafts},
+for details.
+
+@item @code{synopsis}
+A one-line description of the package.
+
+@item @code{description}
+A more elaborate description of the package.
+
+@item @code{license}
+The license of the package; a value from @code{(guix licenses)}.
+
+@item @code{home-page}
+The URL to the home-page of the package, as a string.
+
+@item @code{supported-systems} (default: @var{%supported-systems})
+The list of systems supported by the package, as strings of the form
+@code{architecture-kernel}, for example @code{"x86_64-linux"}.
+
+@item @code{maintainers} (default: @code{'()})
+The list of maintainers of the package, as @code{maintainer} objects.
+
+@item @code{location} (default: source location of the @code{package} form)
+The source location of the package.  It's useful to override this when
+inheriting from another package, in which case this field is not
+automatically corrected.
+@end table
+@end deftp
+
+
+@node origin Reference
+@subsection @code{origin} Reference
+
+This section summarizes all the options available in @code{origin}
+declarations (@pxref{Defining Packages}).
+
+@deftp {Data Type} origin
+This is the data type representing a source code origin.
+
+@table @asis
+@item @code{uri}
+An object containing the URI of the source.  The object type depends on
+the @code{method} (see below).  For example, when using the
+@var{url-fetch} method of @code{(guix download)}, the valid @code{uri}
+values are: a URL represented as a string, or a list thereof.
+
+@item @code{method}
+A procedure that will handle the URI.
+
+Examples include:
+
+@table @asis
+@item @var{url-fetch} from @code{(guix download)}
+download a file the HTTP, HTTPS, or FTP URL specified in the
+@code{uri} field;
+
+@item @var{git-fetch} from @code{(guix git-download)}
+clone the Git version control repository, and check out the revision
+specified in the @code{uri} field as a @code{git-reference} object; a
+@code{git-reference} looks like this:
+
+@example
+(git-reference
+  (url "git://git.debian.org/git/pkg-shadow/shadow")
+  (commit "v4.1.5.1"))
+@end example
+@end table
+
+@item @code{sha256}
+A bytevector containing the SHA-256 hash of the source.  Typically the
+@code{base32} form is used here to generate the bytevector from a
+base-32 string.
+
+@item @code{file-name} (default: @code{#f})
+The file name under which the source code should be saved.  When this is
+@code{#f}, a sensible default value will be used in most cases.  In case
+the source is fetched from a URL, the file name from the URL will be
+used.  For version control checkouts, it's recommended to provide the
+file name explicitly because the default is not very descriptive.
+
+@item @code{patches} (default: @code{'()})
+A list of file names containing patches to be applied to the source.
+
+@item @code{snippet} (default: @code{#f})
+A quoted piece of code that will be run in the source directory to make
+any modifications, which is sometimes more convenient than a patch.
+
+@item @code{patch-flags} (default: @code{'("-p1")})
+A list of command-line flags that should be passed to the @code{patch}
+command.
+
+@item @code{patch-inputs} (default: @code{#f})
+Input packages or derivations to the patching process.  When this is
+@code{#f}, the usual set of inputs necessary for patching are provided,
+such as GNU@tie{}Patch.
+
+@item @code{modules} (default: @code{'()})
+A list of Guile modules that should be loaded during the patching
+process and while running the code in the @code{snippet} field.
+
+@item @code{imported-modules} (default: @code{'()})
+The list of Guile modules to import in the patch derivation, for use by
+the @code{snippet}.
+
+@item @code{patch-guile} (default: @code{#f})
+The Guile package that should be used in the patching process.  When
+this is @code{#f}, a sensible default is used.
+@end table
+@end deftp
+
 
 @node Build Systems
 @section Build Systems
-- 
2.2.1

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

[Ludovic Courtès]

taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>>> +@item @code{imported-modules} (default: @code{'()})
>>
>> The list of Guile modules to import in the patch derivation, for use
>> by the @code{snippet}.
>
> I don't understand how this differs from `modules'?

‘modules’ leads to a ‘use-modules’ form, roughly, whereas
‘imported-modules’ adds the given modules as inputs to the derivation.

>> Could you send an updated patch?
>
> Here it is.  Thanks for all the help!
>
>
> From 8e77504fef71b7679f52d257014a7d85a73a247a Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
>  <taylanbayirli@gmail.com>
> Date: Fri, 15 May 2015 21:54:11 +0200
> Subject: [PATCH] doc: Add "package Reference" and "origin Reference" sections.
>
> * doc/guix.texi (Defining Packages): Link to "package Reference".  Add menu.
> (package Reference, origin Reference): New subsections.

Could you add yourself to the copyright lines at the beginning?

OK to push, thank you!

Ludo’.

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

[Taylan Ulrich Bayırlı/Kammer]

ludo@gnu.org (Ludovic Courtès) writes:

> Could you add yourself to the copyright lines at the beginning?
>
> OK to push, thank you!

Done and pushed, thanks for the help. :-)

Taylan