#+TITLE: Hacking GNU Guix and Its Incredible Distro
-Copyright © 2012, 2013 Ludovic Courtès <ludo@gnu.org>
+Copyright © 2012, 2013, 2014 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
Command-line tools can be used even if you have not run "make install".
directly operate on the syntax tree, such as raising an s-expression or
wrapping it, swallowing or rejecting the following s-expression, etc.
-* Packaging Guidelines
+* 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.
-The GNU distribution is about respecting the freedom of users. Consequently,
-it contains only free software as defined at
-http://www.gnu.org/philosophy/free-sw.html .
+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.
-In addition, we follow the [[http://www.gnu.org/distros/free-system-distribution-guidelines.html][free software distribution guidelines]]. Among other
-things, this means that the distribution tries hard not to steer users towards
-obtaining information about non-free software.
+As you become a regular contributor, you may find it convenient to have write
+access to the repository (see below.)
-* Adding new packages
+* Coding Style
-Package recipes in Guix look like this:
+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.
-#+BEGIN_SRC scheme
- (package
- (name "nettle")
- (version "2.5")
- (source
- (origin
- (method url-fetch)
- (uri (string-append "mirror://gnu/nettle/nettle-"
- version ".tar.gz"))
- (sha256
- (base32
- "0wicr7amx01l03rm0pzgr1qvw3f9blaw17vjsy1301dh13ll58aa"))))
- (build-system gnu-build-system)
- (inputs `(("m4" ,m4)))
- (propagated-inputs `(("gmp" ,gmp)))
- (home-page
- "http://www.lysator.liu.se/~nisse/nettle/")
- (synopsis "GNU Nettle, a cryptographic library")
- (description
- "Nettle is a cryptographic library...")
- (license gpl2+))
-#+END_SRC
+** Programming Paradigm
-Such a recipe can be written by hand, and then tested by running
-‘./pre-inst-env guix build nettle’.
+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.
-When writing the recipe, the base32-encoded SHA256 hash of the source
-code tarball, which can be seen in the example above, can be obtained by
-running:
+** Modules
- guix download http://ftp.gnu.org/gnu/nettle/nettle-2.5.tar.gz
+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.
-Alternatively, it is possible to semi-automatically import recipes from
-the [[http://nixos.org/nixpkgs/][Nixpkgs]] software distribution using this command:
+Modules that deal with the broader GNU system should be in the (gnu …) name
+space rather than (guix …).
- guix import /path/to/nixpkgs/checkout nettle
+** Data Types and Pattern Matching
-The command automatically fetches and converts to Guix the “Nix
-expression” of Nettle.
+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.
-* Submitting Patches
+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.
-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
-bug-guix@gnu.org. Please write commit logs in the [[http://www.gnu.org/prep/standards/html_node/Change-Logs.html#Change-Logs][GNU ChangeLog format]].
+** Formatting Code
-As you become a regular contributor, you may find it convenient to have write
-access to the repository (see below.)
+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 bug-guix@gnu.org.)
+policy below (discussions of the policy can take place on guix-devel@gnu.org.)
-Non-trivial patches should always be posted to bug-guix@gnu.org (trivial
+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. We have a mailing list for commit notifications
+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 bug-guix@gnu.org and leave time for a
+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.
HCoop / jackhill / guix / guix.git / blobdiff