#+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
build system infrastructure using autoconf. It reports an error if an
inappropriate version of the above packages is being used.
-The ‘bootstrap’ script, among other things, invokes ‘git submodule update’; if
-you didn’t run it, you may get the following error:
+If you get an error like this one:
- make: *** No rule to make target `nix/libstore/schema.sql', needed by
- `nix/libstore/schema.sql.hh'
-
-Then, as always, run ‘./configure’. If you get an error like this one:
-
- ./configure: line 6755: `PKG_CHECK_MODULES(GUILE, guile-2.0 >= 2.0.5)'
+ 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
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>.
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]].
+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.)
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.
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’.
HCoop / jackhill / guix / guix.git / blobdiff