* [PATCH] doc: Document native-inputs and propagated-inputs. @ 2015-05-14 20:41 Taylan Ulrich Kammer 2015-05-15 10:32 ` Ludovic Courtès 0 siblings, 1 reply; 7+ messages in thread From: Taylan Ulrich Kammer @ 2015-05-14 20:41 UTC (permalink / raw) To: guix-devel [-- 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 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] doc: Document native-inputs and propagated-inputs. 2015-05-14 20:41 [PATCH] doc: Document native-inputs and propagated-inputs Taylan Ulrich Kammer @ 2015-05-15 10:32 ` Ludovic Courtès 2015-05-15 19:57 ` Taylan Ulrich Bayırlı/Kammer 0 siblings, 1 reply; 7+ messages in thread From: Ludovic Courtès @ 2015-05-15 10:32 UTC (permalink / raw) To: Taylan Ulrich Kammer; +Cc: guix-devel 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’. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] doc: Document native-inputs and propagated-inputs. 2015-05-15 10:32 ` Ludovic Courtès @ 2015-05-15 19:57 ` Taylan Ulrich Bayırlı/Kammer 2015-05-16 19:36 ` Ludovic Courtès 0 siblings, 1 reply; 7+ messages in thread From: Taylan Ulrich Bayırlı/Kammer @ 2015-05-15 19:57 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel [-- 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 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] doc: Document native-inputs and propagated-inputs. 2015-05-15 19:57 ` Taylan Ulrich Bayırlı/Kammer @ 2015-05-16 19:36 ` Ludovic Courtès 2015-05-16 22:58 ` Taylan Ulrich Bayırlı/Kammer 0 siblings, 1 reply; 7+ messages in thread From: Ludovic Courtès @ 2015-05-16 19:36 UTC (permalink / raw) To: Taylan Ulrich "Bayırlı/Kammer"; +Cc: guix-devel 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’. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] doc: Document native-inputs and propagated-inputs. 2015-05-16 19:36 ` Ludovic Courtès @ 2015-05-16 22:58 ` Taylan Ulrich Bayırlı/Kammer 2015-05-19 16:14 ` Ludovic Courtès 0 siblings, 1 reply; 7+ messages in thread From: Taylan Ulrich Bayırlı/Kammer @ 2015-05-16 22:58 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel [-- 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 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] doc: Document native-inputs and propagated-inputs. 2015-05-16 22:58 ` Taylan Ulrich Bayırlı/Kammer @ 2015-05-19 16:14 ` Ludovic Courtès 2015-05-19 18:17 ` Taylan Ulrich Bayırlı/Kammer 0 siblings, 1 reply; 7+ messages in thread From: Ludovic Courtès @ 2015-05-19 16:14 UTC (permalink / raw) To: Taylan Ulrich "Bayırlı/Kammer"; +Cc: guix-devel 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’. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] doc: Document native-inputs and propagated-inputs. 2015-05-19 16:14 ` Ludovic Courtès @ 2015-05-19 18:17 ` Taylan Ulrich Bayırlı/Kammer 0 siblings, 0 replies; 7+ messages in thread From: Taylan Ulrich Bayırlı/Kammer @ 2015-05-19 18:17 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-05-19 18:17 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-05-14 20:41 [PATCH] doc: Document native-inputs and propagated-inputs Taylan Ulrich Kammer 2015-05-15 10:32 ` Ludovic Courtès 2015-05-15 19:57 ` Taylan Ulrich Bayırlı/Kammer 2015-05-16 19:36 ` Ludovic Courtès 2015-05-16 22:58 ` Taylan Ulrich Bayırlı/Kammer 2015-05-19 16:14 ` Ludovic Courtès 2015-05-19 18:17 ` Taylan Ulrich Bayırlı/Kammer
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.