* [PATCH] doc: Merge 'HACKING' into Texinfo manual.
@ 2015-06-09 11:42 Mathieu Lirzin
2015-06-10 8:09 ` Ludovic Courtès
2015-06-10 8:21 ` Alex Kost
0 siblings, 2 replies; 8+ messages in thread
From: Mathieu Lirzin @ 2015-06-09 11:42 UTC (permalink / raw)
To: guix-devel
[-- Attachment #1: Type: text/plain, Size: 205 bytes --]
Hello Guix,
This patch will need an update when Alex recent patch (doc: Add
'help2man' to HACKING.) will be pushed.
do 'HACKING' copyright notices need to be added to the manual too?
--
Mathieu Lirzin
[-- Attachment #2: 0001-doc-Merge-HACKING-into-Texinfo-manual.patch --]
[-- Type: text/x-diff, Size: 22084 bytes --]
From ccbbddb5d5335b3714a4e6204498f1fc24dca6ab Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin <mthl@openmailbox.org>
Date: Tue, 9 Jun 2015 00:08:43 +0200
Subject: [PATCH] doc: Merge 'HACKING' into Texinfo manual.
* HACKING: Delete file.
(Building from Git, The Perfect Setup, Coding Style, Submitting Patches):
Move to ...
* doc/guix.texi (Running Guix Before It Is Installed): Likewise.
(Contributing): ... here.
* README (Installation): Adapt to it.
* configure.ac (DOT): Likewise.
* Makefile.am (EXTRA_DIST): Likewise.
---
HACKING | 163 -------------------------------------
Makefile.am | 1 -
README | 4 +-
configure.ac | 2 +-
doc/guix.texi | 254 +++++++++++++++++++++++++++++++++++++++++++++++-----------
5 files changed, 212 insertions(+), 212 deletions(-)
delete mode 100644 HACKING
diff --git a/HACKING b/HACKING
deleted file mode 100644
index cf10ba5..0000000
--- a/HACKING
+++ /dev/null
@@ -1,163 +0,0 @@
--*- mode: org; coding: utf-8; -*-
-
-#+TITLE: Hacking GNU Guix and Its Incredible Distro
-
-Copyright © 2012, 2013, 2014, 2015 Ludovic Courtès <ludo@gnu.org>
-Copyright © 2013 Nikita Karetnikov <nikita@karetnikov.org>
-Copyright © 2014 Pierre-Antoine Rault <par@rigelk.eu>
-
- Copying and distribution of this file, with or without modification,
- are permitted in any medium without royalty provided the copyright
- notice and this notice are preserved.
-
-
-* Building from Git
-
-When building Guix from a checkout, the following packages are required in
-addition to those mentioned in the installation instructions:
-
- - [[http://www.gnu.org/software/autoconf/][GNU Autoconf]]
- - [[http://www.gnu.org/software/automake/][GNU Automake]]
- - [[http://www.gnu.org/software/gettext/][GNU Gettext]]
- - [[http://www.graphviz.org/][Graphviz]]
-
-Run ‘./bootstrap’ to download the Nix daemon source code and to generate the
-build system infrastructure using autoconf. It reports an error if an
-inappropriate version of the above packages is being used.
-
-If you get an error like this one:
-
- configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES
-
-it probably means that Autoconf couldn’t find ‘pkg.m4’, which is provided by
-pkg-config. Make sure that ‘pkg.m4’ is available. For instance, if you
-installed Automake in ‘/usr/local’, it wouldn’t look for ‘.m4’ files in
-‘/usr/share’. So you have to invoke the following command in that case
-
- $ export ACLOCAL_PATH=/usr/share/aclocal
-
-See “info '(automake) Macro Search Path'” for more information.
-
-Then, run ‘./configure’ as usual.
-
-Finally, you have to invoke ‘make check’ to run tests. If anything fails,
-take a look at “info '(guix) Installation'” or send a message to
-<guix-devel@gnu.org>.
-
-* Running Guix before it is installed
-
-See the same-named section in the manual.
-
-* The Perfect Setup
-
-The Perfect Setup to hack on Guix is basically the perfect setup used
-for Guile hacking (info "(guile) Using Guile in Emacs"). First, you
-need more than an editor, you need [[http://www.gnu.org/software/emacs][Emacs]], empowered by the wonderful
-[[http://nongnu.org/geiser/][Geiser]].
-
-Geiser allows for interactive and incremental development from within
-Emacs: code compilation and evaluation from within buffers, access to
-on-line documentation (docstrings), context-sensitive completion, M-. to
-jump to an object definition, a REPL to try out your code, and more.
-
-To actually edit the code, Emacs already has a neat Scheme mode. But in
-addition to that, you must not miss [[http://www.emacswiki.org/emacs/ParEdit][Paredit]]. It provides facilities to
-directly operate on the syntax tree, such as raising an s-expression or
-wrapping it, swallowing or rejecting the following s-expression, etc.
-
-* Submitting Patches
-
-Development is done using the Git distributed version control system. Thus,
-access to the repository is not strictly necessary. We welcome contributions
-in the form of patches as produced by ‘git format-patch’ sent to
-guix-devel@gnu.org. Please write commit logs in the [[http://www.gnu.org/prep/standards/html_node/Change-Logs.html#Change-Logs][GNU ChangeLog
-format]]; you can check the commit history for examples.
-
-Before submitting a patch that adds or modifies a package definition, please
-run ‘guix lint PACKAGE’, where PACKAGE is the name of the new or modified
-package, and fix any errors it reports. In addition, please make sure the
-package builds on your platform, using ‘guix build’. You may also want to
-check that dependent package (if applicable) are not affected by the change;
-‘guix refresh --list-dependent PACKAGE’ will help you do that.
-
-When posting a patch to the mailing list, use "[PATCH] ..." as a subject. You
-may use your email client or the ‘git send-mail’ command.
-
-As you become a regular contributor, you may find it convenient to have write
-access to the repository (see below.)
-
-* Coding Style
-
-In general our code follows the [[info:standards][GNU Coding Standards]] (GCS). However, the GCS
-do not say much about Scheme, so here are some additional rules.
-
-** Programming Paradigm
-
-Scheme code in Guix is written in a purely functional style. One exception is
-code that involves input/output, and procedures that implement low-level
-concepts, such as the ‘memoize’ procedure.
-
-** Modules
-
-Guile modules that are meant to be used on the builder side must live in the
-(guix build …) name space. They must not refer to other Guix or GNU modules.
-However, it is OK for a “host-side” module to use a build-side module.
-
-Modules that deal with the broader GNU system should be in the (gnu …) name
-space rather than (guix …).
-
-** Data Types and Pattern Matching
-
-The tendency in classical Lisp is to use lists to represent everything, and
-then to browse them “by hand” using ‘car’, ‘cdr’, ‘cadr’, and co. There are
-several problems with that style, notably the fact that it is hard to read,
-error-prone, and a hindrance to proper type error reports.
-
-Guix code should define appropriate data types (for instance, using
-‘define-record-type*’) rather than abuse lists. In addition, it should use
-pattern matching, via Guile’s (ice-9 match) module, especially when matching
-lists.
-
-** Formatting Code
-
-When writing Scheme code, we follow common wisdom among Scheme programmers.
-In general, we follow the [[http://mumble.net/~campbell/scheme/style.txt][Riastradh's Lisp Style Rules]]. This document happens
-to describe the conventions mostly used in Guile’s code too. It is very
-thoughtful and well written, so please do read it.
-
-Some special forms introduced in Guix, such as the ‘substitute*’ macro, have
-special indentation rules. These are defined in the .dir-locals.el file,
-which Emacs automatically uses. If you do not use Emacs, please make sure to
-let your editor know the rules.
-
-We require all top-level procedures to carry a docstring. This requirement
-can be relaxed for simple private procedures in the (guix build …) name space,
-though.
-
-Procedures should not have more than four positional parameters. Use keyword
-parameters for procedures that take more than four parameters.
-
-* Commit Access
-
-For frequent contributors, having write access to the repository is
-convenient. When you deem it necessary, feel free to ask for it on the
-mailing list. When you get commit access, please make sure to follow the
-policy below (discussions of the policy can take place on guix-devel@gnu.org.)
-
-Non-trivial patches should always be posted to guix-devel@gnu.org (trivial
-patches include fixing typos, etc.)
-
-For patches that just add a new package, and a simple one, it’s OK to commit,
-if you’re confident (which means you successfully built it in a chroot setup,
-and have done a reasonable copyright and license auditing.) Likewise for
-package upgrades, except upgrades that trigger a lot of rebuilds (for example,
-upgrading GnuTLS or GLib.) We have a mailing list for commit notifications
-(guix-commits@gnu.org), so people can notice. Before pushing your changes,
-make sure to run ‘git pull --rebase’.
-
-For anything else, please post to guix-devel@gnu.org and leave time for a
-review, without committing anything. If you didn’t receive any reply
-after two weeks, and if you’re confident, it’s OK to commit.
-
-That last part is subject to being adjusted, allowing individuals to commit
-directly on non-controversial changes on parts they’re familiar with.
diff --git a/Makefile.am b/Makefile.am
index 6478aeb..3f458ff 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -249,7 +249,6 @@ dist_pkgdata_DATA = hydra.gnu.org.pub
dist_bashcompletion_DATA = etc/completion/bash/guix
EXTRA_DIST = \
- HACKING \
ROADMAP \
TODO \
.dir-locals.el \
diff --git a/README b/README
index 4d3367e..df52822 100644
--- a/README
+++ b/README
@@ -46,8 +46,8 @@ See the manual for the installation instructions, either by running
or by checking the [[http://www.gnu.org/software/guix/manual/guix.html#Installation][web copy of the manual]].
-For information on installation from a Git checkout, please see the ‘HACKING’
-file.
+For information on installation from a Git checkout, please see the section
+"Building from Git" in the manual.
* Installing Guix from Guix
diff --git a/configure.ac b/configure.ac
index 50b65fd..2c8b9f0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -179,7 +179,7 @@ AC_CACHE_SAVE
m4_include([config-daemon.ac])
dnl `dot' (from the Graphviz package) is only needed for maintainers.
-dnl See `HACKING' for more info.
+dnl See `Building from Git' in the manual for more info.
AM_MISSING_PROG([DOT], [dot])
dnl Manual pages.
diff --git a/doc/guix.texi b/doc/guix.texi
index c62e44e..e9ee637 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -13,7 +13,8 @@
Copyright @copyright{} 2012, 2013, 2014, 2015 Ludovic Courtès@*
Copyright @copyright{} 2013, 2014 Andreas Enge@*
Copyright @copyright{} 2013 Nikita Karetnikov@*
-Copyright @copyright{} 2015 Taylan Ulrich Bayırlı/Kammer
+Copyright @copyright{} 2015 Taylan Ulrich Bayırlı/Kammer@*
+Copyright @copyright{} 2015 Mathieu Lirzin
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
@@ -88,7 +89,6 @@ Installation
* Running the Test Suite:: Testing Guix.
* Setting Up the Daemon:: Preparing the build daemon's environment.
* Invoking guix-daemon:: Running the build daemon.
-* Running Guix Before It Is Installed:: Hacker tricks.
Setting Up the Daemon
@@ -253,7 +253,6 @@ instead, you want to install the complete GNU operating system,
* Running the Test Suite:: Testing Guix.
* Setting Up the Daemon:: Preparing the build daemon's environment.
* Invoking guix-daemon:: Running the build daemon.
-* Running Guix Before It Is Installed:: Hacker tricks.
@end menu
@node Binary Installation
@@ -847,44 +846,6 @@ useful in exceptional circumstances, such as if you need to run several
daemons on the same machine.
@end table
-@node Running Guix Before It Is Installed
-@section Running Guix Before It Is Installed
-
-If you are hacking Guix itself---which is a good idea!---you will find
-it useful to test the changes made in your local source tree checkout
-without actually installing them.
-
-To that end, all the command-line tools can be used even if you have not
-run @command{make install}. To do that, prefix each command with
-@command{./pre-inst-env} (the @file{pre-inst-env} script lives in the
-top build tree of Guix), as in:
-
-@example
-$ sudo ./pre-inst-env guix-daemon --build-users-group=guixbuild
-$ ./pre-inst-env guix build hello
-@end example
-
-@noindent
-Similarly, for a Guile session using the Guix modules:
-
-@example
-$ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))'
-@end example
-
-The @command{pre-inst-env} script sets up all the environment variables
-necessary to support this, including @code{PATH} and
-@code{GUILE_LOAD_PATH}.
-
-If you are hacking Guix from Emacs using the wonderful Geiser
-(@pxref{Introduction,,, geiser, Geiser User Manual}), make sure to
-augment Guile's load path so that it finds source files from your
-checkout:
-
-@lisp
-;; Assuming the Guix checkout is in ~/src/guix.
-(add-to-list 'geiser-guile-load-path "~/src/guix")
-@end lisp
-
@c *********************************************************************
@node Package Management
@@ -6780,10 +6741,213 @@ grow! Please get in touch with us on @email{guix-devel@@gnu.org} and
reports, patches, and anything that may be helpful to the project. We
particularly welcome help on packaging (@pxref{Packaging Guidelines}).
-Please see the
-@url{http://git.savannah.gnu.org/cgit/guix.git/tree/HACKING,
-@file{HACKING} file} that comes with the Guix source code for practical
-details about contributions.
+@menu
+* Building from Git:: The latest and greatest.
+* Running Guix Before It Is Installed:: Hacker tricks.
+* The Perfect Setup:: The right tools.
+* Coding Style:: Hygiene of the contributor.
+* Submitting Patches:: Share your work.
+@end menu
+
+
+@node Building from Git
+@section Building from Git
+
+If you want to hack Guix itself, it is recommended to use the latest
+version from the Git repository. When building Guix from a checkout,
+the following packages are required in addition to those mentioned in
+the installation instructions (@pxref{Requirements}).
+
+@itemize
+@item @url{http://gnu.org/software/autoconf/, GNU Autoconf};
+@item @url{http://gnu.org/software/automake/, GNU Automake};
+@item @url{http://gnu.org/software/gettext/, GNU Gettext};
+@item @url{http://www.graphviz.org/, Graphviz}.
+@end itemize
+
+Run @command{./bootstrap} to download the Nix daemon source code and to
+generate the build system infrastructure using autoconf. It reports an
+error if an inappropriate version of the above packages is being used.
+
+@noindent
+If you get an error like this one:
+
+@example
+configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES
+@end example
+
+it probably means that Autoconf couldn’t find @file{pkg.m4}, which is
+provided by @command{pkg-config}. Make sure that @file{pkg.m4} is
+available. For instance, if you installed Automake in
+@file{/usr/local}, it wouldn’t look for @file{.m4} files in
+@file{/usr/share}. So you have to invoke the following command in that
+case
+
+@example
+export ACLOCAL_PATH=/usr/share/aclocal
+@end example
+
+See @pxref{Macro Search Path,,, automake, The GNU Automake Manual} for
+more information.
+
+Then, run @command{./configure} as usual.
+
+Finally, you have to invoke @code{make check} to run tests. If anything
+fails, take a look at installation instructions (@pxref{Installation})
+or send a message to the @email{guix-devel@@gnu.org, mailing list}.
+
+
+@node Running Guix Before It Is Installed
+@section Running Guix Before It Is Installed
+
+In order to keep a sane working environment, you will find it useful to
+test the changes made in your local source tree checkout without
+actually installing them. So that you can distinguish between your
+``end-user'' hat and your ``motley'' costume.
+
+To that end, all the command-line tools can be used even if you have not
+run @code{make install}. To do that, prefix each command with
+@command{./pre-inst-env} (the @file{pre-inst-env} script lives in the
+top build tree of Guix), as in:
+
+@example
+$ sudo ./pre-inst-env guix-daemon --build-users-group=guixbuild
+$ ./pre-inst-env guix build hello
+@end example
+
+@noindent
+Similarly, for a Guile session using the Guix modules:
+
+@example
+$ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))'
+@end example
+
+The @command{pre-inst-env} script sets up all the environment variables
+necessary to support this, including @env{PATH} and @env{GUILE_LOAD_PATH}.
+
+
+@node The Perfect Setup
+@section The Perfect Setup
+
+The Perfect Setup to hack on Guix is basically the perfect setup used
+for Guile hacking (@pxref{Using Guile in Emacs,,, guile, Guile Reference
+Manual}). First, you need more than an editor, you need
+@url{http://www.gnu.org/software/emacs, Emacs}, empowered by the
+wonderful @url{http://nongnu.org/geiser/, Geiser}.
+
+Geiser allows for interactive and incremental development from within
+Emacs: code compilation and evaluation from within buffers, access to
+on-line documentation (docstrings), context-sensitive completion,
+@kbd{M-.} to jump to an object definition, a REPL to try out your code,
+and more (@pxref{Introduction,,, geiser, Geiser User Manual}). For
+convenient Guix development, make sure to augment Guile’s load path so
+that it finds source files from your checkout:
+
+@lisp
+;; @r{Assuming the Guix checkout is in ~/src/guix.}
+(add-to-list 'geiser-guile-load-path "~/src/guix")
+@end lisp
+
+To actually edit the code, Emacs already has a neat Scheme mode. But in
+addition to that, you must not miss
+@url{http://www.emacswiki.org/emacs/ParEdit, Paredit}. It provides
+facilities to directly operate on the syntax tree, such as raising an
+s-expression or wrapping it, swallowing or rejecting the following
+s-expression, etc.
+
+
+@node Coding Style
+@section Coding Style
+
+In general our code follows the GNU Coding Standards (@pxref{Top,,,
+standards, GNU Coding Standards}). However, they do not say much about
+Scheme, so here are some additional rules.
+
+@menu
+* Programming Paradigm:: How to compose your elements.
+* Modules:: Where to store your code?
+* Data Types and Pattern Matching:: Implementing data structures.
+* Formatting Code:: Writing conventions.
+@end menu
+
+@node Programming Paradigm
+@subsection Programming Paradigm
+
+Scheme code in Guix is written in a purely functional style. One
+exception is code that involves input/output, and procedures that
+implement low-level concepts, such as the @code{memoize} procedure.
+
+@node Modules
+@subsection Modules
+
+Guile modules that are meant to be used on the builder side must live in
+the @code{(guix build ...)} name space. They must not refer to other Guix
+or GNU modules. However, it is OK for a ``host-side'' module to use a
+build-side module.
+
+Modules that deal with the broader GNU system should be in the
+@code{(gnu ...)} name space rather than @code{(guix ...)}.
+
+@node Data Types and Pattern Matching
+@subsection Data Types and Pattern Matching
+
+The tendency in classical Lisp is to use lists to represent everything,
+and then to browse them ``by hand'' using @code{car}, @code{cdr},
+@code{cadr}, and co. There are several problems with that style,
+notably the fact that it is hard to read, error-prone, and a hindrance
+to proper type error reports.
+
+Guix code should define appropriate data types (for instance, using
+@code{define-record-type*}) rather than abuse lists. In addition, it
+should use pattern matching, via Guile’s @code{(ice-9 match)} module,
+especially when matching lists.
+
+@node Formatting Code
+@subsection Formatting Code
+
+When writing Scheme code, we follow common wisdom among Scheme
+programmers. In general, we follow the
+@url{http://mumble.net/~campbell/scheme/style.txt, Riastradh's Lisp
+Style Rules}. This document happens to describe the conventions mostly
+used in Guile’s code too. It is very thoughtful and well written, so
+please do read it.
+
+Some special forms introduced in Guix, such as the @code{substitute*}
+macro, have special indentation rules. These are defined in the
+@file{.dir-locals.el} file, which Emacs automatically uses. If you do
+not use Emacs, please make sure to let your editor know the rules.
+
+We require all top-level procedures to carry a docstring. This
+requirement can be relaxed for simple private procedures in the
+@code{(guix build ...)} name space, though.
+
+Procedures should not have more than four positional parameters. Use
+keyword parameters for procedures that take more than four parameters.
+
+
+@node Submitting Patches
+@section Submitting Patches
+
+Development is done using the Git distributed version control system.
+Thus, access to the repository is not strictly necessary. We welcome
+contributions in the form of patches as produced by @code{git
+format-patch} sent to the @email{guix-devel@@gnu.org, mailing list}.
+Please write commit logs in the ChangeLog format (@pxref{Change Logs,,,
+Standards, GNU Coding Standards}); you can check the commit history for
+examples.
+
+Before submitting a patch that adds or modifies a package definition,
+please run @code{guix lint @var{package}}, where @var{package} is the
+name of the new or modified package, and fix any errors it reports. In
+addition, please make sure the package builds on your platform, using
+@code{guix build @var{package}}. You may also want to check that
+dependent package (if applicable) are not affected by the change;
+@code{guix refresh --list-dependent @var{package}} will help you do
+that.
+
+When posting a patch to the mailing list, use @samp{[PATCH] ...} as a
+subject. You may use your email client or the @command{git send-mail}
+command.
@c *********************************************************************
--
2.1.4
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] doc: Merge 'HACKING' into Texinfo manual.
2015-06-09 11:42 [PATCH] doc: Merge 'HACKING' into Texinfo manual Mathieu Lirzin
@ 2015-06-10 8:09 ` Ludovic Courtès
2015-06-10 8:21 ` Alex Kost
1 sibling, 0 replies; 8+ messages in thread
From: Ludovic Courtès @ 2015-06-10 8:09 UTC (permalink / raw)
To: Mathieu Lirzin; +Cc: guix-devel
Mathieu Lirzin <mthl@openmailbox.org> skribis:
> do 'HACKING' copyright notices need to be added to the manual too?
Yes, please. (We may have to compress the copyright lines eventually
for the PS/PDF output.)
> From ccbbddb5d5335b3714a4e6204498f1fc24dca6ab Mon Sep 17 00:00:00 2001
> From: Mathieu Lirzin <mthl@openmailbox.org>
> Date: Tue, 9 Jun 2015 00:08:43 +0200
> Subject: [PATCH] doc: Merge 'HACKING' into Texinfo manual.
>
> * HACKING: Delete file.
> (Building from Git, The Perfect Setup, Coding Style, Submitting Patches):
> Move to ...
> * doc/guix.texi (Running Guix Before It Is Installed): Likewise.
> (Contributing): ... here.
> * README (Installation): Adapt to it.
> * configure.ac (DOT): Likewise.
> * Makefile.am (EXTRA_DIST): Likewise.
LGTM, but it removes a bit too much: The “Commit Access” section
vanished. Could you leave ‘HACKING’ with that section and a sentence
telling users to look at the “Contributing” section of the manual?
> +Please write commit logs in the ChangeLog format (@pxref{Change Logs,,,
> +Standards, GNU Coding Standards}); you can check the commit history for
^
Should be lowercase “standards” (the name of the Info file.)
> +examples.
> +
> +Before submitting a patch that adds or modifies a package definition,
> +please run @code{guix lint @var{package}}, where @var{package} is the
> +name of the new or modified package, and fix any errors it reports. In
^
Add: (@pxref{Invoking guix lint}).
> +addition, please make sure the package builds on your platform, using
> +@code{guix build @var{package}}. You may also want to check that
> +dependent package (if applicable) are not affected by the change;
> +@code{guix refresh --list-dependent @var{package}} will help you do
> +that.
^
Add: (@pxref{Invoking guix refresh}).
Could you send an updated patch?
Thanks for working on it!
Ludo’.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] doc: Merge 'HACKING' into Texinfo manual.
2015-06-09 11:42 [PATCH] doc: Merge 'HACKING' into Texinfo manual Mathieu Lirzin
2015-06-10 8:09 ` Ludovic Courtès
@ 2015-06-10 8:21 ` Alex Kost
2015-06-10 12:30 ` Mathieu Lirzin
1 sibling, 1 reply; 8+ messages in thread
From: Alex Kost @ 2015-06-10 8:21 UTC (permalink / raw)
To: Mathieu Lirzin; +Cc: guix-devel
Mathieu Lirzin (2015-06-09 14:42 +0300) wrote:
> Hello Guix,
>
> This patch will need an update when Alex recent patch (doc: Add
> 'help2man' to HACKING.) will be pushed.
(Sorry for the delay). I suppose it would be better not to push my
redundant patch. Could you just add a line for 'help2man' to your
patch?
[...]
> +Modules that deal with the broader GNU system should be in the
> +@code{(gnu ...)} name space rather than @code{(guix ...)}.
I would use '@dots{}' instead of '...' there, although I see that the
real "hardcoded" dots are used in some places of ‘guix.texi’, so I don't
really know if we have a convention on that subject.
--
Alex
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] doc: Merge 'HACKING' into Texinfo manual.
2015-06-10 8:21 ` Alex Kost
@ 2015-06-10 12:30 ` Mathieu Lirzin
2015-06-10 14:11 ` Alex Kost
2015-06-10 19:52 ` Ludovic Courtès
0 siblings, 2 replies; 8+ messages in thread
From: Mathieu Lirzin @ 2015-06-10 12:30 UTC (permalink / raw)
To: Alex Kost, Ludovic Courtès; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 1402 bytes --]
Alex Kost <alezost@gmail.com> writes:
> (Sorry for the delay). I suppose it would be better not to push my
> redundant patch. Could you just add a line for 'help2man' to your
> patch?
Your patch is not related to the move, so IMO it would be more
appropriate to keep a separate commit for your patch.
>> +Modules that deal with the broader GNU system should be in the
>> +@code{(gnu ...)} name space rather than @code{(guix ...)}.
>
> I would use '@dots{}' instead of '...' there, although I see that the
> real "hardcoded" dots are used in some places of ‘guix.texi’, so I don't
> really know if we have a convention on that subject.
I looked at the Texinfo manual, and I think '@dots{}' fill its purposes
when used in text since it's referenced in "Glyphs for text" section. I
don't know if it's intended to be used in code snippets. I have put
this glyphs in my patch, but I think it would need more discussions.
Ludovic Courtès <ludo@gnu.org> writes:
>> do 'HACKING' copyright notices need to be added to the manual too?
>
>Yes, please. (We may have to compress the copyright lines eventually
>for the PS/PDF output.)
Please check if it's ok for you. I used "MA"git-blame ;-) in order to
adapt the copyright notices. How do we sort alphabetically "Taylan
Ulrich Bayırlı/Kammer" name?
Thanks to both you for the review,
--
Mathieu Lirzin
[-- Attachment #2: 0001-doc-Move-most-HACKING-informations-into-the-manual.patch --]
[-- Type: text/x-diff, Size: 20684 bytes --]
From 624e5e248f23563c8fb98e82d6c2bd5f25531e6c Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin <mthl@openmailbox.org>
Date: Wed, 10 Jun 2015 13:39:54 +0200
Subject: [PATCH] doc: Move most 'HACKING' informations into the manual.
* HACKING (Contributing): New section.
(Building from Git, The Perfect Setup, Coding Style, Submitting Patches):
Move to ...
* doc/guix.texi (Running Guix Before It Is Installed): Likewise.
(Contributing): ... here.
* README (Installation): Adapt to it.
* configure.ac (DOT): Likewise.
---
HACKING | 132 ++----------------------------
README | 4 +-
configure.ac | 2 +-
doc/guix.texi | 253 ++++++++++++++++++++++++++++++++++++++++++++++++----------
4 files changed, 218 insertions(+), 173 deletions(-)
diff --git a/HACKING b/HACKING
index cf10ba5..41838ee 100644
--- a/HACKING
+++ b/HACKING
@@ -2,140 +2,20 @@
#+TITLE: Hacking GNU Guix and Its Incredible Distro
-Copyright © 2012, 2013, 2014, 2015 Ludovic Courtès <ludo@gnu.org>
-Copyright © 2013 Nikita Karetnikov <nikita@karetnikov.org>
-Copyright © 2014 Pierre-Antoine Rault <par@rigelk.eu>
+Copyright © 2012, 2013, 2014 Ludovic Courtès <ludo@gnu.org>
+Copyright © 2015 Mathieu Lirzin <mthl@openmailbox.org>
Copying and distribution of this file, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved.
+* Contributing
-* Building from Git
+See the manual for useful hacking informations, either by running
-When building Guix from a checkout, the following packages are required in
-addition to those mentioned in the installation instructions:
+ info -f doc/guix.info "(guix) Contributing"
- - [[http://www.gnu.org/software/autoconf/][GNU Autoconf]]
- - [[http://www.gnu.org/software/automake/][GNU Automake]]
- - [[http://www.gnu.org/software/gettext/][GNU Gettext]]
- - [[http://www.graphviz.org/][Graphviz]]
-
-Run ‘./bootstrap’ to download the Nix daemon source code and to generate the
-build system infrastructure using autoconf. It reports an error if an
-inappropriate version of the above packages is being used.
-
-If you get an error like this one:
-
- configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES
-
-it probably means that Autoconf couldn’t find ‘pkg.m4’, which is provided by
-pkg-config. Make sure that ‘pkg.m4’ is available. For instance, if you
-installed Automake in ‘/usr/local’, it wouldn’t look for ‘.m4’ files in
-‘/usr/share’. So you have to invoke the following command in that case
-
- $ export ACLOCAL_PATH=/usr/share/aclocal
-
-See “info '(automake) Macro Search Path'” for more information.
-
-Then, run ‘./configure’ as usual.
-
-Finally, you have to invoke ‘make check’ to run tests. If anything fails,
-take a look at “info '(guix) Installation'” or send a message to
-<guix-devel@gnu.org>.
-
-* Running Guix before it is installed
-
-See the same-named section in the manual.
-
-* The Perfect Setup
-
-The Perfect Setup to hack on Guix is basically the perfect setup used
-for Guile hacking (info "(guile) Using Guile in Emacs"). First, you
-need more than an editor, you need [[http://www.gnu.org/software/emacs][Emacs]], empowered by the wonderful
-[[http://nongnu.org/geiser/][Geiser]].
-
-Geiser allows for interactive and incremental development from within
-Emacs: code compilation and evaluation from within buffers, access to
-on-line documentation (docstrings), context-sensitive completion, M-. to
-jump to an object definition, a REPL to try out your code, and more.
-
-To actually edit the code, Emacs already has a neat Scheme mode. But in
-addition to that, you must not miss [[http://www.emacswiki.org/emacs/ParEdit][Paredit]]. It provides facilities to
-directly operate on the syntax tree, such as raising an s-expression or
-wrapping it, swallowing or rejecting the following s-expression, etc.
-
-* Submitting Patches
-
-Development is done using the Git distributed version control system. Thus,
-access to the repository is not strictly necessary. We welcome contributions
-in the form of patches as produced by ‘git format-patch’ sent to
-guix-devel@gnu.org. Please write commit logs in the [[http://www.gnu.org/prep/standards/html_node/Change-Logs.html#Change-Logs][GNU ChangeLog
-format]]; you can check the commit history for examples.
-
-Before submitting a patch that adds or modifies a package definition, please
-run ‘guix lint PACKAGE’, where PACKAGE is the name of the new or modified
-package, and fix any errors it reports. In addition, please make sure the
-package builds on your platform, using ‘guix build’. You may also want to
-check that dependent package (if applicable) are not affected by the change;
-‘guix refresh --list-dependent PACKAGE’ will help you do that.
-
-When posting a patch to the mailing list, use "[PATCH] ..." as a subject. You
-may use your email client or the ‘git send-mail’ command.
-
-As you become a regular contributor, you may find it convenient to have write
-access to the repository (see below.)
-
-* Coding Style
-
-In general our code follows the [[info:standards][GNU Coding Standards]] (GCS). However, the GCS
-do not say much about Scheme, so here are some additional rules.
-
-** Programming Paradigm
-
-Scheme code in Guix is written in a purely functional style. One exception is
-code that involves input/output, and procedures that implement low-level
-concepts, such as the ‘memoize’ procedure.
-
-** Modules
-
-Guile modules that are meant to be used on the builder side must live in the
-(guix build …) name space. They must not refer to other Guix or GNU modules.
-However, it is OK for a “host-side” module to use a build-side module.
-
-Modules that deal with the broader GNU system should be in the (gnu …) name
-space rather than (guix …).
-
-** Data Types and Pattern Matching
-
-The tendency in classical Lisp is to use lists to represent everything, and
-then to browse them “by hand” using ‘car’, ‘cdr’, ‘cadr’, and co. There are
-several problems with that style, notably the fact that it is hard to read,
-error-prone, and a hindrance to proper type error reports.
-
-Guix code should define appropriate data types (for instance, using
-‘define-record-type*’) rather than abuse lists. In addition, it should use
-pattern matching, via Guile’s (ice-9 match) module, especially when matching
-lists.
-
-** Formatting Code
-
-When writing Scheme code, we follow common wisdom among Scheme programmers.
-In general, we follow the [[http://mumble.net/~campbell/scheme/style.txt][Riastradh's Lisp Style Rules]]. This document happens
-to describe the conventions mostly used in Guile’s code too. It is very
-thoughtful and well written, so please do read it.
-
-Some special forms introduced in Guix, such as the ‘substitute*’ macro, have
-special indentation rules. These are defined in the .dir-locals.el file,
-which Emacs automatically uses. If you do not use Emacs, please make sure to
-let your editor know the rules.
-
-We require all top-level procedures to carry a docstring. This requirement
-can be relaxed for simple private procedures in the (guix build …) name space,
-though.
-
-Procedures should not have more than four positional parameters. Use keyword
-parameters for procedures that take more than four parameters.
+or by checking the [[http://www.gnu.org/software/guix/manual/guix.html#Contributing][web copy of the manual]].
* Commit Access
diff --git a/README b/README
index 4d3367e..df52822 100644
--- a/README
+++ b/README
@@ -46,8 +46,8 @@ See the manual for the installation instructions, either by running
or by checking the [[http://www.gnu.org/software/guix/manual/guix.html#Installation][web copy of the manual]].
-For information on installation from a Git checkout, please see the ‘HACKING’
-file.
+For information on installation from a Git checkout, please see the section
+"Building from Git" in the manual.
* Installing Guix from Guix
diff --git a/configure.ac b/configure.ac
index 50b65fd..2c8b9f0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -179,7 +179,7 @@ AC_CACHE_SAVE
m4_include([config-daemon.ac])
dnl `dot' (from the Graphviz package) is only needed for maintainers.
-dnl See `HACKING' for more info.
+dnl See `Building from Git' in the manual for more info.
AM_MISSING_PROG([DOT], [dot])
dnl Manual pages.
diff --git a/doc/guix.texi b/doc/guix.texi
index be7a292..2d78672 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -13,6 +13,8 @@
Copyright @copyright{} 2012, 2013, 2014, 2015 Ludovic Courtès@*
Copyright @copyright{} 2013, 2014 Andreas Enge@*
Copyright @copyright{} 2013 Nikita Karetnikov@*
+Copyright @copyright{} 2015 Mathieu Lirzin@*
+Copyright @copyright{} 2014 Pierre-Antoine Rault@*
Copyright @copyright{} 2015 Taylan Ulrich Bayırlı/Kammer
Permission is granted to copy, distribute and/or modify this document
@@ -88,7 +90,6 @@ Installation
* Running the Test Suite:: Testing Guix.
* Setting Up the Daemon:: Preparing the build daemon's environment.
* Invoking guix-daemon:: Running the build daemon.
-* Running Guix Before It Is Installed:: Hacker tricks.
Setting Up the Daemon
@@ -253,7 +254,6 @@ instead, you want to install the complete GNU operating system,
* Running the Test Suite:: Testing Guix.
* Setting Up the Daemon:: Preparing the build daemon's environment.
* Invoking guix-daemon:: Running the build daemon.
-* Running Guix Before It Is Installed:: Hacker tricks.
@end menu
@node Binary Installation
@@ -847,44 +847,6 @@ useful in exceptional circumstances, such as if you need to run several
daemons on the same machine.
@end table
-@node Running Guix Before It Is Installed
-@section Running Guix Before It Is Installed
-
-If you are hacking Guix itself---which is a good idea!---you will find
-it useful to test the changes made in your local source tree checkout
-without actually installing them.
-
-To that end, all the command-line tools can be used even if you have not
-run @command{make install}. To do that, prefix each command with
-@command{./pre-inst-env} (the @file{pre-inst-env} script lives in the
-top build tree of Guix), as in:
-
-@example
-$ sudo ./pre-inst-env guix-daemon --build-users-group=guixbuild
-$ ./pre-inst-env guix build hello
-@end example
-
-@noindent
-Similarly, for a Guile session using the Guix modules:
-
-@example
-$ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))'
-@end example
-
-The @command{pre-inst-env} script sets up all the environment variables
-necessary to support this, including @code{PATH} and
-@code{GUILE_LOAD_PATH}.
-
-If you are hacking Guix from Emacs using the wonderful Geiser
-(@pxref{Introduction,,, geiser, Geiser User Manual}), make sure to
-augment Guile's load path so that it finds source files from your
-checkout:
-
-@lisp
-;; Assuming the Guix checkout is in ~/src/guix.
-(add-to-list 'geiser-guile-load-path "~/src/guix")
-@end lisp
-
@c *********************************************************************
@node Package Management
@@ -6792,10 +6754,213 @@ grow! Please get in touch with us on @email{guix-devel@@gnu.org} and
reports, patches, and anything that may be helpful to the project. We
particularly welcome help on packaging (@pxref{Packaging Guidelines}).
-Please see the
-@url{http://git.savannah.gnu.org/cgit/guix.git/tree/HACKING,
-@file{HACKING} file} that comes with the Guix source code for practical
-details about contributions.
+@menu
+* Building from Git:: The latest and greatest.
+* Running Guix Before It Is Installed:: Hacker tricks.
+* The Perfect Setup:: The right tools.
+* Coding Style:: Hygiene of the contributor.
+* Submitting Patches:: Share your work.
+@end menu
+
+
+@node Building from Git
+@section Building from Git
+
+If you want to hack Guix itself, it is recommended to use the latest
+version from the Git repository. When building Guix from a checkout,
+the following packages are required in addition to those mentioned in
+the installation instructions (@pxref{Requirements}).
+
+@itemize
+@item @url{http://gnu.org/software/autoconf/, GNU Autoconf};
+@item @url{http://gnu.org/software/automake/, GNU Automake};
+@item @url{http://gnu.org/software/gettext/, GNU Gettext};
+@item @url{http://www.graphviz.org/, Graphviz}.
+@end itemize
+
+Run @command{./bootstrap} to download the Nix daemon source code and to
+generate the build system infrastructure using autoconf. It reports an
+error if an inappropriate version of the above packages is being used.
+
+@noindent
+If you get an error like this one:
+
+@example
+configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES
+@end example
+
+it probably means that Autoconf couldn’t find @file{pkg.m4}, which is
+provided by @command{pkg-config}. Make sure that @file{pkg.m4} is
+available. For instance, if you installed Automake in
+@file{/usr/local}, it wouldn’t look for @file{.m4} files in
+@file{/usr/share}. So you have to invoke the following command in that
+case
+
+@example
+export ACLOCAL_PATH=/usr/share/aclocal
+@end example
+
+See @pxref{Macro Search Path,,, automake, The GNU Automake Manual} for
+more information.
+
+Then, run @command{./configure} as usual.
+
+Finally, you have to invoke @code{make check} to run tests. If anything
+fails, take a look at installation instructions (@pxref{Installation})
+or send a message to the @email{guix-devel@@gnu.org, mailing list}.
+
+
+@node Running Guix Before It Is Installed
+@section Running Guix Before It Is Installed
+
+In order to keep a sane working environment, you will find it useful to
+test the changes made in your local source tree checkout without
+actually installing them. So that you can distinguish between your
+``end-user'' hat and your ``motley'' costume.
+
+To that end, all the command-line tools can be used even if you have not
+run @code{make install}. To do that, prefix each command with
+@command{./pre-inst-env} (the @file{pre-inst-env} script lives in the
+top build tree of Guix), as in:
+
+@example
+$ sudo ./pre-inst-env guix-daemon --build-users-group=guixbuild
+$ ./pre-inst-env guix build hello
+@end example
+
+@noindent
+Similarly, for a Guile session using the Guix modules:
+
+@example
+$ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))'
+@end example
+
+The @command{pre-inst-env} script sets up all the environment variables
+necessary to support this, including @env{PATH} and @env{GUILE_LOAD_PATH}.
+
+
+@node The Perfect Setup
+@section The Perfect Setup
+
+The Perfect Setup to hack on Guix is basically the perfect setup used
+for Guile hacking (@pxref{Using Guile in Emacs,,, guile, Guile Reference
+Manual}). First, you need more than an editor, you need
+@url{http://www.gnu.org/software/emacs, Emacs}, empowered by the
+wonderful @url{http://nongnu.org/geiser/, Geiser}.
+
+Geiser allows for interactive and incremental development from within
+Emacs: code compilation and evaluation from within buffers, access to
+on-line documentation (docstrings), context-sensitive completion,
+@kbd{M-.} to jump to an object definition, a REPL to try out your code,
+and more (@pxref{Introduction,,, geiser, Geiser User Manual}). For
+convenient Guix development, make sure to augment Guile’s load path so
+that it finds source files from your checkout:
+
+@lisp
+;; @r{Assuming the Guix checkout is in ~/src/guix.}
+(add-to-list 'geiser-guile-load-path "~/src/guix")
+@end lisp
+
+To actually edit the code, Emacs already has a neat Scheme mode. But in
+addition to that, you must not miss
+@url{http://www.emacswiki.org/emacs/ParEdit, Paredit}. It provides
+facilities to directly operate on the syntax tree, such as raising an
+s-expression or wrapping it, swallowing or rejecting the following
+s-expression, etc.
+
+
+@node Coding Style
+@section Coding Style
+
+In general our code follows the GNU Coding Standards (@pxref{Top,,,
+standards, GNU Coding Standards}). However, they do not say much about
+Scheme, so here are some additional rules.
+
+@menu
+* Programming Paradigm:: How to compose your elements.
+* Modules:: Where to store your code?
+* Data Types and Pattern Matching:: Implementing data structures.
+* Formatting Code:: Writing conventions.
+@end menu
+
+@node Programming Paradigm
+@subsection Programming Paradigm
+
+Scheme code in Guix is written in a purely functional style. One
+exception is code that involves input/output, and procedures that
+implement low-level concepts, such as the @code{memoize} procedure.
+
+@node Modules
+@subsection Modules
+
+Guile modules that are meant to be used on the builder side must live in
+the @code{(guix build @dots{})} name space. They must not refer to
+other Guix or GNU modules. However, it is OK for a ``host-side'' module
+to use a build-side module.
+
+Modules that deal with the broader GNU system should be in the
+@code{(gnu @dots{})} name space rather than @code{(guix @dots{})}.
+
+@node Data Types and Pattern Matching
+@subsection Data Types and Pattern Matching
+
+The tendency in classical Lisp is to use lists to represent everything,
+and then to browse them ``by hand'' using @code{car}, @code{cdr},
+@code{cadr}, and co. There are several problems with that style,
+notably the fact that it is hard to read, error-prone, and a hindrance
+to proper type error reports.
+
+Guix code should define appropriate data types (for instance, using
+@code{define-record-type*}) rather than abuse lists. In addition, it
+should use pattern matching, via Guile’s @code{(ice-9 match)} module,
+especially when matching lists.
+
+@node Formatting Code
+@subsection Formatting Code
+
+When writing Scheme code, we follow common wisdom among Scheme
+programmers. In general, we follow the
+@url{http://mumble.net/~campbell/scheme/style.txt, Riastradh's Lisp
+Style Rules}. This document happens to describe the conventions mostly
+used in Guile’s code too. It is very thoughtful and well written, so
+please do read it.
+
+Some special forms introduced in Guix, such as the @code{substitute*}
+macro, have special indentation rules. These are defined in the
+@file{.dir-locals.el} file, which Emacs automatically uses. If you do
+not use Emacs, please make sure to let your editor know the rules.
+
+We require all top-level procedures to carry a docstring. This
+requirement can be relaxed for simple private procedures in the
+@code{(guix build @dots{})} name space, though.
+
+Procedures should not have more than four positional parameters. Use
+keyword parameters for procedures that take more than four parameters.
+
+
+@node Submitting Patches
+@section Submitting Patches
+
+Development is done using the Git distributed version control system.
+Thus, access to the repository is not strictly necessary. We welcome
+contributions in the form of patches as produced by @code{git
+format-patch} sent to the @email{guix-devel@@gnu.org, mailing list}.
+Please write commit logs in the ChangeLog format (@pxref{Change Logs,,,
+standards, GNU Coding Standards}); you can check the commit history for
+examples.
+
+Before submitting a patch that adds or modifies a package definition,
+please run @code{guix lint @var{package}}, where @var{package} is the
+name of the new or modified package, and fix any errors it reports
+(@pxref{Invoking guix lint}). In addition, please make sure the package
+builds on your platform, using @code{guix build @var{package}}. You may
+also want to check that dependent package (if applicable) are not
+affected by the change; @code{guix refresh --list-dependent
+@var{package}} will help you do that (@pxref{Invoking guix refresh}).
+
+When posting a patch to the mailing list, use @samp{[PATCH] @dots{}} as a
+subject. You may use your email client or the @command{git send-mail}
+command.
@c *********************************************************************
--
2.1.4
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] doc: Merge 'HACKING' into Texinfo manual.
2015-06-10 12:30 ` Mathieu Lirzin
@ 2015-06-10 14:11 ` Alex Kost
2015-06-10 19:52 ` Ludovic Courtès
1 sibling, 0 replies; 8+ messages in thread
From: Alex Kost @ 2015-06-10 14:11 UTC (permalink / raw)
To: Mathieu Lirzin; +Cc: guix-devel
Mathieu Lirzin (2015-06-10 15:30 +0300) wrote:
> Alex Kost <alezost@gmail.com> writes:
>
>> (Sorry for the delay). I suppose it would be better not to push my
>> redundant patch. Could you just add a line for 'help2man' to your
>> patch?
>
> Your patch is not related to the move, so IMO it would be more
> appropriate to keep a separate commit for your patch.
OK, the power is on your side this time :-) (Ludovic has pushed my patch)
>>> +Modules that deal with the broader GNU system should be in the
>>> +@code{(gnu ...)} name space rather than @code{(guix ...)}.
>>
>> I would use '@dots{}' instead of '...' there, although I see that the
>> real "hardcoded" dots are used in some places of ‘guix.texi’, so I don't
>> really know if we have a convention on that subject.
>
> I looked at the Texinfo manual, and I think '@dots{}' fill its purposes
> when used in text since it's referenced in "Glyphs for text" section. I
> don't know if it's intended to be used in code snippets. I have put
> this glyphs in my patch, but I think it would need more discussions.
Sorry, I didn't meant to force you to change that right away. I'm
totally for discussion.
--
Alex
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] doc: Merge 'HACKING' into Texinfo manual.
2015-06-10 12:30 ` Mathieu Lirzin
2015-06-10 14:11 ` Alex Kost
@ 2015-06-10 19:52 ` Ludovic Courtès
2015-06-10 22:23 ` Mathieu Lirzin
1 sibling, 1 reply; 8+ messages in thread
From: Ludovic Courtès @ 2015-06-10 19:52 UTC (permalink / raw)
To: Mathieu Lirzin; +Cc: guix-devel, Alex Kost
Mathieu Lirzin <mthl@openmailbox.org> skribis:
> Alex Kost <alezost@gmail.com> writes:
[...]
>>> +Modules that deal with the broader GNU system should be in the
>>> +@code{(gnu ...)} name space rather than @code{(guix ...)}.
>>
>> I would use '@dots{}' instead of '...' there, although I see that the
>> real "hardcoded" dots are used in some places of ‘guix.texi’, so I don't
>> really know if we have a convention on that subject.
>
> I looked at the Texinfo manual, and I think '@dots{}' fill its purposes
> when used in text since it's referenced in "Glyphs for text" section. I
> don't know if it's intended to be used in code snippets. I have put
> this glyphs in my patch, but I think it would need more discussions.
I think @dots{} is appropriate in this case (even though it’s probably
not used it consistently in the rest of the manual.) It’s basically
equivalent to inserting HORIZONTAL ELLIPSIS, which is what we want.
>>Yes, please. (We may have to compress the copyright lines eventually
>>for the PS/PDF output.)
>
> Please check if it's ok for you. I used "MA"git-blame ;-) in order to
> adapt the copyright notices. How do we sort alphabetically "Taylan
> Ulrich Bayırlı/Kammer" name?
Good question, I’m not sure. Taylan?
> From 624e5e248f23563c8fb98e82d6c2bd5f25531e6c Mon Sep 17 00:00:00 2001
> From: Mathieu Lirzin <mthl@openmailbox.org>
> Date: Wed, 10 Jun 2015 13:39:54 +0200
> Subject: [PATCH] doc: Move most 'HACKING' informations into the manual.
>
> * HACKING (Contributing): New section.
> (Building from Git, The Perfect Setup, Coding Style, Submitting Patches):
> Move to ...
> * doc/guix.texi (Running Guix Before It Is Installed): Likewise.
> (Contributing): ... here.
> * README (Installation): Adapt to it.
> * configure.ac (DOT): Likewise.
LGTM, please push!
Ludo’.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] doc: Merge 'HACKING' into Texinfo manual.
2015-06-10 19:52 ` Ludovic Courtès
@ 2015-06-10 22:23 ` Mathieu Lirzin
2015-06-11 14:05 ` Ludovic Courtès
0 siblings, 1 reply; 8+ messages in thread
From: Mathieu Lirzin @ 2015-06-10 22:23 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel, Alex Kost
[-- Attachment #1: Type: text/plain, Size: 167 bytes --]
ludo@gnu.org (Ludovic Courtès) writes:
> LGTM, please push!
I noticed that I have forgot to update the detailed node listing.
Here is the updated patch. :/
[-- Attachment #2: 0001-doc-Move-most-HACKING-informations-into-the-manual.patch --]
[-- Type: text/x-diff, Size: 21533 bytes --]
From 51ac59f58dea877226827f5779e659aacdedf8a8 Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin <mthl@openmailbox.org>
Date: Wed, 10 Jun 2015 13:39:54 +0200
Subject: [PATCH] doc: Move most 'HACKING' informations into the manual.
* HACKING (Contributing): New section.
(Building from Git, The Perfect Setup, Coding Style, Submitting Patches):
Move to ...
* doc/guix.texi (Running Guix Before It Is Installed): Likewise.
(Contributing): ... here.
* README (Installation): Adapt to it.
* configure.ac (DOT): Likewise.
---
HACKING | 133 ++---------------------------
README | 4 +-
configure.ac | 2 +-
doc/guix.texi | 268 ++++++++++++++++++++++++++++++++++++++++++++++++----------
4 files changed, 233 insertions(+), 174 deletions(-)
diff --git a/HACKING b/HACKING
index 1e742c8..41838ee 100644
--- a/HACKING
+++ b/HACKING
@@ -2,141 +2,20 @@
#+TITLE: Hacking GNU Guix and Its Incredible Distro
-Copyright © 2012, 2013, 2014, 2015 Ludovic Courtès <ludo@gnu.org>
-Copyright © 2013 Nikita Karetnikov <nikita@karetnikov.org>
-Copyright © 2014 Pierre-Antoine Rault <par@rigelk.eu>
+Copyright © 2012, 2013, 2014 Ludovic Courtès <ludo@gnu.org>
+Copyright © 2015 Mathieu Lirzin <mthl@openmailbox.org>
Copying and distribution of this file, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved.
+* Contributing
-* Building from Git
+See the manual for useful hacking informations, either by running
-When building Guix from a checkout, the following packages are required in
-addition to those mentioned in the installation instructions:
+ info -f doc/guix.info "(guix) Contributing"
- - [[http://www.gnu.org/software/autoconf/][GNU Autoconf]]
- - [[http://www.gnu.org/software/automake/][GNU Automake]]
- - [[http://www.gnu.org/software/gettext/][GNU Gettext]]
- - [[http://www.graphviz.org/][Graphviz]]
- - [[http://www.gnu.org/software/help2man/][GNU Help2man]] (optional)
-
-Run ‘./bootstrap’ to download the Nix daemon source code and to generate the
-build system infrastructure using autoconf. It reports an error if an
-inappropriate version of the above packages is being used.
-
-If you get an error like this one:
-
- configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES
-
-it probably means that Autoconf couldn’t find ‘pkg.m4’, which is provided by
-pkg-config. Make sure that ‘pkg.m4’ is available. For instance, if you
-installed Automake in ‘/usr/local’, it wouldn’t look for ‘.m4’ files in
-‘/usr/share’. So you have to invoke the following command in that case
-
- $ export ACLOCAL_PATH=/usr/share/aclocal
-
-See “info '(automake) Macro Search Path'” for more information.
-
-Then, run ‘./configure’ as usual.
-
-Finally, you have to invoke ‘make check’ to run tests. If anything fails,
-take a look at “info '(guix) Installation'” or send a message to
-<guix-devel@gnu.org>.
-
-* Running Guix before it is installed
-
-See the same-named section in the manual.
-
-* The Perfect Setup
-
-The Perfect Setup to hack on Guix is basically the perfect setup used
-for Guile hacking (info "(guile) Using Guile in Emacs"). First, you
-need more than an editor, you need [[http://www.gnu.org/software/emacs][Emacs]], empowered by the wonderful
-[[http://nongnu.org/geiser/][Geiser]].
-
-Geiser allows for interactive and incremental development from within
-Emacs: code compilation and evaluation from within buffers, access to
-on-line documentation (docstrings), context-sensitive completion, M-. to
-jump to an object definition, a REPL to try out your code, and more.
-
-To actually edit the code, Emacs already has a neat Scheme mode. But in
-addition to that, you must not miss [[http://www.emacswiki.org/emacs/ParEdit][Paredit]]. It provides facilities to
-directly operate on the syntax tree, such as raising an s-expression or
-wrapping it, swallowing or rejecting the following s-expression, etc.
-
-* Submitting Patches
-
-Development is done using the Git distributed version control system. Thus,
-access to the repository is not strictly necessary. We welcome contributions
-in the form of patches as produced by ‘git format-patch’ sent to
-guix-devel@gnu.org. Please write commit logs in the [[http://www.gnu.org/prep/standards/html_node/Change-Logs.html#Change-Logs][GNU ChangeLog
-format]]; you can check the commit history for examples.
-
-Before submitting a patch that adds or modifies a package definition, please
-run ‘guix lint PACKAGE’, where PACKAGE is the name of the new or modified
-package, and fix any errors it reports. In addition, please make sure the
-package builds on your platform, using ‘guix build’. You may also want to
-check that dependent package (if applicable) are not affected by the change;
-‘guix refresh --list-dependent PACKAGE’ will help you do that.
-
-When posting a patch to the mailing list, use "[PATCH] ..." as a subject. You
-may use your email client or the ‘git send-mail’ command.
-
-As you become a regular contributor, you may find it convenient to have write
-access to the repository (see below.)
-
-* Coding Style
-
-In general our code follows the [[info:standards][GNU Coding Standards]] (GCS). However, the GCS
-do not say much about Scheme, so here are some additional rules.
-
-** Programming Paradigm
-
-Scheme code in Guix is written in a purely functional style. One exception is
-code that involves input/output, and procedures that implement low-level
-concepts, such as the ‘memoize’ procedure.
-
-** Modules
-
-Guile modules that are meant to be used on the builder side must live in the
-(guix build …) name space. They must not refer to other Guix or GNU modules.
-However, it is OK for a “host-side” module to use a build-side module.
-
-Modules that deal with the broader GNU system should be in the (gnu …) name
-space rather than (guix …).
-
-** Data Types and Pattern Matching
-
-The tendency in classical Lisp is to use lists to represent everything, and
-then to browse them “by hand” using ‘car’, ‘cdr’, ‘cadr’, and co. There are
-several problems with that style, notably the fact that it is hard to read,
-error-prone, and a hindrance to proper type error reports.
-
-Guix code should define appropriate data types (for instance, using
-‘define-record-type*’) rather than abuse lists. In addition, it should use
-pattern matching, via Guile’s (ice-9 match) module, especially when matching
-lists.
-
-** Formatting Code
-
-When writing Scheme code, we follow common wisdom among Scheme programmers.
-In general, we follow the [[http://mumble.net/~campbell/scheme/style.txt][Riastradh's Lisp Style Rules]]. This document happens
-to describe the conventions mostly used in Guile’s code too. It is very
-thoughtful and well written, so please do read it.
-
-Some special forms introduced in Guix, such as the ‘substitute*’ macro, have
-special indentation rules. These are defined in the .dir-locals.el file,
-which Emacs automatically uses. If you do not use Emacs, please make sure to
-let your editor know the rules.
-
-We require all top-level procedures to carry a docstring. This requirement
-can be relaxed for simple private procedures in the (guix build …) name space,
-though.
-
-Procedures should not have more than four positional parameters. Use keyword
-parameters for procedures that take more than four parameters.
+or by checking the [[http://www.gnu.org/software/guix/manual/guix.html#Contributing][web copy of the manual]].
* Commit Access
diff --git a/README b/README
index 4d3367e..df52822 100644
--- a/README
+++ b/README
@@ -46,8 +46,8 @@ See the manual for the installation instructions, either by running
or by checking the [[http://www.gnu.org/software/guix/manual/guix.html#Installation][web copy of the manual]].
-For information on installation from a Git checkout, please see the ‘HACKING’
-file.
+For information on installation from a Git checkout, please see the section
+"Building from Git" in the manual.
* Installing Guix from Guix
diff --git a/configure.ac b/configure.ac
index 50b65fd..2c8b9f0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -179,7 +179,7 @@ AC_CACHE_SAVE
m4_include([config-daemon.ac])
dnl `dot' (from the Graphviz package) is only needed for maintainers.
-dnl See `HACKING' for more info.
+dnl See `Building from Git' in the manual for more info.
AM_MISSING_PROG([DOT], [dot])
dnl Manual pages.
diff --git a/doc/guix.texi b/doc/guix.texi
index be7a292..d75ffba 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -13,6 +13,8 @@
Copyright @copyright{} 2012, 2013, 2014, 2015 Ludovic Courtès@*
Copyright @copyright{} 2013, 2014 Andreas Enge@*
Copyright @copyright{} 2013 Nikita Karetnikov@*
+Copyright @copyright{} 2015 Mathieu Lirzin@*
+Copyright @copyright{} 2014 Pierre-Antoine Rault@*
Copyright @copyright{} 2015 Taylan Ulrich Bayırlı/Kammer
Permission is granted to copy, distribute and/or modify this document
@@ -88,7 +90,6 @@ Installation
* Running the Test Suite:: Testing Guix.
* Setting Up the Daemon:: Preparing the build daemon's environment.
* Invoking guix-daemon:: Running the build daemon.
-* Running Guix Before It Is Installed:: Hacker tricks.
Setting Up the Daemon
@@ -177,6 +178,21 @@ Packaging Guidelines
* Perl Modules:: Little pearls.
* Fonts:: Fond of fonts.
+Contributing
+
+* Building from Git:: The latest and greatest.
+* Running Guix Before It Is Installed:: Hacker tricks.
+* The Perfect Setup:: The right tools.
+* Coding Style:: Hygiene of the contributor.
+* Submitting Patches:: Share your work.
+
+Coding Style
+
+* Programming Paradigm:: How to compose your elements.
+* Modules:: Where to store your code?
+* Data Types and Pattern Matching:: Implementing data structures.
+* Formatting Code:: Writing conventions.
+
@end detailmenu
@end menu
@@ -253,7 +269,6 @@ instead, you want to install the complete GNU operating system,
* Running the Test Suite:: Testing Guix.
* Setting Up the Daemon:: Preparing the build daemon's environment.
* Invoking guix-daemon:: Running the build daemon.
-* Running Guix Before It Is Installed:: Hacker tricks.
@end menu
@node Binary Installation
@@ -847,44 +862,6 @@ useful in exceptional circumstances, such as if you need to run several
daemons on the same machine.
@end table
-@node Running Guix Before It Is Installed
-@section Running Guix Before It Is Installed
-
-If you are hacking Guix itself---which is a good idea!---you will find
-it useful to test the changes made in your local source tree checkout
-without actually installing them.
-
-To that end, all the command-line tools can be used even if you have not
-run @command{make install}. To do that, prefix each command with
-@command{./pre-inst-env} (the @file{pre-inst-env} script lives in the
-top build tree of Guix), as in:
-
-@example
-$ sudo ./pre-inst-env guix-daemon --build-users-group=guixbuild
-$ ./pre-inst-env guix build hello
-@end example
-
-@noindent
-Similarly, for a Guile session using the Guix modules:
-
-@example
-$ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))'
-@end example
-
-The @command{pre-inst-env} script sets up all the environment variables
-necessary to support this, including @code{PATH} and
-@code{GUILE_LOAD_PATH}.
-
-If you are hacking Guix from Emacs using the wonderful Geiser
-(@pxref{Introduction,,, geiser, Geiser User Manual}), make sure to
-augment Guile's load path so that it finds source files from your
-checkout:
-
-@lisp
-;; Assuming the Guix checkout is in ~/src/guix.
-(add-to-list 'geiser-guile-load-path "~/src/guix")
-@end lisp
-
@c *********************************************************************
@node Package Management
@@ -6792,10 +6769,213 @@ grow! Please get in touch with us on @email{guix-devel@@gnu.org} and
reports, patches, and anything that may be helpful to the project. We
particularly welcome help on packaging (@pxref{Packaging Guidelines}).
-Please see the
-@url{http://git.savannah.gnu.org/cgit/guix.git/tree/HACKING,
-@file{HACKING} file} that comes with the Guix source code for practical
-details about contributions.
+@menu
+* Building from Git:: The latest and greatest.
+* Running Guix Before It Is Installed:: Hacker tricks.
+* The Perfect Setup:: The right tools.
+* Coding Style:: Hygiene of the contributor.
+* Submitting Patches:: Share your work.
+@end menu
+
+@node Building from Git
+@section Building from Git
+
+If you want to hack Guix itself, it is recommended to use the latest
+version from the Git repository. When building Guix from a checkout,
+the following packages are required in addition to those mentioned in
+the installation instructions (@pxref{Requirements}).
+
+@itemize
+@item @url{http://gnu.org/software/autoconf/, GNU Autoconf};
+@item @url{http://gnu.org/software/automake/, GNU Automake};
+@item @url{http://gnu.org/software/gettext/, GNU Gettext};
+@item @url{http://www.graphviz.org/, Graphviz};
+@item @url{http://www.gnu.org/software/help2man/, GNU Help2man (optional)}.
+@end itemize
+
+Run @command{./bootstrap} to download the Nix daemon source code and to
+generate the build system infrastructure using autoconf. It reports an
+error if an inappropriate version of the above packages is being used.
+
+@noindent
+If you get an error like this one:
+
+@example
+configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES
+@end example
+
+it probably means that Autoconf couldn’t find @file{pkg.m4}, which is
+provided by @command{pkg-config}. Make sure that @file{pkg.m4} is
+available. For instance, if you installed Automake in
+@file{/usr/local}, it wouldn’t look for @file{.m4} files in
+@file{/usr/share}. So you have to invoke the following command in that
+case
+
+@example
+export ACLOCAL_PATH=/usr/share/aclocal
+@end example
+
+See @pxref{Macro Search Path,,, automake, The GNU Automake Manual} for
+more information.
+
+Then, run @command{./configure} as usual.
+
+Finally, you have to invoke @code{make check} to run tests. If anything
+fails, take a look at installation instructions (@pxref{Installation})
+or send a message to the @email{guix-devel@@gnu.org, mailing list}.
+
+
+@node Running Guix Before It Is Installed
+@section Running Guix Before It Is Installed
+
+In order to keep a sane working environment, you will find it useful to
+test the changes made in your local source tree checkout without
+actually installing them. So that you can distinguish between your
+``end-user'' hat and your ``motley'' costume.
+
+To that end, all the command-line tools can be used even if you have not
+run @code{make install}. To do that, prefix each command with
+@command{./pre-inst-env} (the @file{pre-inst-env} script lives in the
+top build tree of Guix), as in:
+
+@example
+$ sudo ./pre-inst-env guix-daemon --build-users-group=guixbuild
+$ ./pre-inst-env guix build hello
+@end example
+
+@noindent
+Similarly, for a Guile session using the Guix modules:
+
+@example
+$ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))'
+@end example
+
+The @command{pre-inst-env} script sets up all the environment variables
+necessary to support this, including @env{PATH} and @env{GUILE_LOAD_PATH}.
+
+
+@node The Perfect Setup
+@section The Perfect Setup
+
+The Perfect Setup to hack on Guix is basically the perfect setup used
+for Guile hacking (@pxref{Using Guile in Emacs,,, guile, Guile Reference
+Manual}). First, you need more than an editor, you need
+@url{http://www.gnu.org/software/emacs, Emacs}, empowered by the
+wonderful @url{http://nongnu.org/geiser/, Geiser}.
+
+Geiser allows for interactive and incremental development from within
+Emacs: code compilation and evaluation from within buffers, access to
+on-line documentation (docstrings), context-sensitive completion,
+@kbd{M-.} to jump to an object definition, a REPL to try out your code,
+and more (@pxref{Introduction,,, geiser, Geiser User Manual}). For
+convenient Guix development, make sure to augment Guile’s load path so
+that it finds source files from your checkout:
+
+@lisp
+;; @r{Assuming the Guix checkout is in ~/src/guix.}
+(add-to-list 'geiser-guile-load-path "~/src/guix")
+@end lisp
+
+To actually edit the code, Emacs already has a neat Scheme mode. But in
+addition to that, you must not miss
+@url{http://www.emacswiki.org/emacs/ParEdit, Paredit}. It provides
+facilities to directly operate on the syntax tree, such as raising an
+s-expression or wrapping it, swallowing or rejecting the following
+s-expression, etc.
+
+
+@node Coding Style
+@section Coding Style
+
+In general our code follows the GNU Coding Standards (@pxref{Top,,,
+standards, GNU Coding Standards}). However, they do not say much about
+Scheme, so here are some additional rules.
+
+@menu
+* Programming Paradigm:: How to compose your elements.
+* Modules:: Where to store your code?
+* Data Types and Pattern Matching:: Implementing data structures.
+* Formatting Code:: Writing conventions.
+@end menu
+
+@node Programming Paradigm
+@subsection Programming Paradigm
+
+Scheme code in Guix is written in a purely functional style. One
+exception is code that involves input/output, and procedures that
+implement low-level concepts, such as the @code{memoize} procedure.
+
+@node Modules
+@subsection Modules
+
+Guile modules that are meant to be used on the builder side must live in
+the @code{(guix build @dots{})} name space. They must not refer to
+other Guix or GNU modules. However, it is OK for a ``host-side'' module
+to use a build-side module.
+
+Modules that deal with the broader GNU system should be in the
+@code{(gnu @dots{})} name space rather than @code{(guix @dots{})}.
+
+@node Data Types and Pattern Matching
+@subsection Data Types and Pattern Matching
+
+The tendency in classical Lisp is to use lists to represent everything,
+and then to browse them ``by hand'' using @code{car}, @code{cdr},
+@code{cadr}, and co. There are several problems with that style,
+notably the fact that it is hard to read, error-prone, and a hindrance
+to proper type error reports.
+
+Guix code should define appropriate data types (for instance, using
+@code{define-record-type*}) rather than abuse lists. In addition, it
+should use pattern matching, via Guile’s @code{(ice-9 match)} module,
+especially when matching lists.
+
+@node Formatting Code
+@subsection Formatting Code
+
+When writing Scheme code, we follow common wisdom among Scheme
+programmers. In general, we follow the
+@url{http://mumble.net/~campbell/scheme/style.txt, Riastradh's Lisp
+Style Rules}. This document happens to describe the conventions mostly
+used in Guile’s code too. It is very thoughtful and well written, so
+please do read it.
+
+Some special forms introduced in Guix, such as the @code{substitute*}
+macro, have special indentation rules. These are defined in the
+@file{.dir-locals.el} file, which Emacs automatically uses. If you do
+not use Emacs, please make sure to let your editor know the rules.
+
+We require all top-level procedures to carry a docstring. This
+requirement can be relaxed for simple private procedures in the
+@code{(guix build @dots{})} name space, though.
+
+Procedures should not have more than four positional parameters. Use
+keyword parameters for procedures that take more than four parameters.
+
+
+@node Submitting Patches
+@section Submitting Patches
+
+Development is done using the Git distributed version control system.
+Thus, access to the repository is not strictly necessary. We welcome
+contributions in the form of patches as produced by @code{git
+format-patch} sent to the @email{guix-devel@@gnu.org, mailing list}.
+Please write commit logs in the ChangeLog format (@pxref{Change Logs,,,
+standards, GNU Coding Standards}); you can check the commit history for
+examples.
+
+Before submitting a patch that adds or modifies a package definition,
+please run @code{guix lint @var{package}}, where @var{package} is the
+name of the new or modified package, and fix any errors it reports
+(@pxref{Invoking guix lint}). In addition, please make sure the package
+builds on your platform, using @code{guix build @var{package}}. You may
+also want to check that dependent package (if applicable) are not
+affected by the change; @code{guix refresh --list-dependent
+@var{package}} will help you do that (@pxref{Invoking guix refresh}).
+
+When posting a patch to the mailing list, use @samp{[PATCH] @dots{}} as a
+subject. You may use your email client or the @command{git send-mail}
+command.
@c *********************************************************************
--
2.1.4
[-- Attachment #3: Type: text/plain, Size: 19 bytes --]
--
Mathieu Lirzin
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] doc: Merge 'HACKING' into Texinfo manual.
2015-06-10 22:23 ` Mathieu Lirzin
@ 2015-06-11 14:05 ` Ludovic Courtès
0 siblings, 0 replies; 8+ messages in thread
From: Ludovic Courtès @ 2015-06-11 14:05 UTC (permalink / raw)
To: Mathieu Lirzin; +Cc: guix-devel, Alex Kost
Mathieu Lirzin <mthl@openmailbox.org> skribis:
> ludo@gnu.org (Ludovic Courtès) writes:
>
>> LGTM, please push!
>
> I noticed that I have forgot to update the detailed node listing.
> Here is the updated patch. :/
Ah sure.
> From 51ac59f58dea877226827f5779e659aacdedf8a8 Mon Sep 17 00:00:00 2001
> From: Mathieu Lirzin <mthl@openmailbox.org>
> Date: Wed, 10 Jun 2015 13:39:54 +0200
> Subject: [PATCH] doc: Move most 'HACKING' informations into the manual.
>
> * HACKING (Contributing): New section.
> (Building from Git, The Perfect Setup, Coding Style, Submitting Patches):
> Move to ...
> * doc/guix.texi (Running Guix Before It Is Installed): Likewise.
> (Contributing): ... here.
> * README (Installation): Adapt to it.
> * configure.ac (DOT): Likewise.
Now that I think of it, could you move the whole “Contributing” section
in a new contributing.texi file? (Possibly in a subsequent commit, if
that’s more convenient for you.)
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2015-06-11 14:05 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-06-09 11:42 [PATCH] doc: Merge 'HACKING' into Texinfo manual Mathieu Lirzin
2015-06-10 8:09 ` Ludovic Courtès
2015-06-10 8:21 ` Alex Kost
2015-06-10 12:30 ` Mathieu Lirzin
2015-06-10 14:11 ` Alex Kost
2015-06-10 19:52 ` Ludovic Courtès
2015-06-10 22:23 ` Mathieu Lirzin
2015-06-11 14:05 ` Ludovic Courtès
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.