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.
* doc/contributing.texi: ... here. New file.
* doc.am (EXTRA_DIST): Use it.
* README (Installation): Adapt to it.
* configure.ac (DOT): Likewise.

1 files changed, 6 insertions, 127 deletions

diff --git a/HACKING b/HACKING
index 1e742c8454..41838ee816 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