You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 

180 lines
7.9 KiB

  1. -*- mode: org; coding: utf-8; -*-
  2. #+TITLE: Hacking GNU Guix and Its Incredible Distro
  3. Copyright © 2012, 2013, 2014 Ludovic Courtès <ludo@gnu.org>
  4. Copyright © 2013 Nikita Karetnikov <nikita@karetnikov.org>
  5. Copyright © 2014 Pierre-Antoine Rault <par@rigelk.eu>
  6. Copying and distribution of this file, with or without modification,
  7. are permitted in any medium without royalty provided the copyright
  8. notice and this notice are preserved.
  9. * Building from Git
  10. When building Guix from a checkout, the following packages are required in
  11. addition to those mentioned in the installation instructions:
  12. - [[http://www.gnu.org/software/autoconf/][GNU Autoconf]]
  13. - [[http://www.gnu.org/software/automake/][GNU Automake]]
  14. - [[http://www.gnu.org/software/gettext/][GNU Gettext]]
  15. - [[http://www.graphviz.org/][Graphviz]]
  16. Run ‘./bootstrap’ to download the Nix daemon source code and to generate the
  17. build system infrastructure using autoconf. It reports an error if an
  18. inappropriate version of the above packages is being used.
  19. The ‘bootstrap’ script, among other things, invokes ‘git submodule update’; if
  20. you didn’t run it, you may get the following error:
  21. make: *** No rule to make target `nix/libstore/schema.sql', needed by
  22. `nix/libstore/schema.sql.hh'
  23. If you get an error like this one:
  24. configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES
  25. it probably means that Autoconf couldn’t find ‘pkg.m4’, which is provided by
  26. pkg-config. Make sure that ‘pkg.m4’ is available. For instance, if you
  27. installed Automake in ‘/usr/local’, it wouldn’t look for ‘.m4’ files in
  28. ‘/usr/share’. So you have to invoke the following command in that case
  29. $ export ACLOCAL_PATH=/usr/share/aclocal
  30. See “info '(automake) Macro Search Path'” for more information.
  31. Then, run ‘./configure’ as usual.
  32. Finally, you have to invoke ‘make check’ to run tests. If anything fails,
  33. take a look at “info '(guix) Installation'” or send a message to
  34. <guix-devel@gnu.org>.
  35. * Running Guix before it is installed
  36. Command-line tools can be used even if you have not run "make install".
  37. To do that, prefix each command with ‘./pre-inst-env’, as in:
  38. ./pre-inst-env guix build --help
  39. Similarly, for a Guile session using the Guix modules:
  40. ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))'
  41. The ‘pre-inst-env’ script sets up all the environment variables
  42. necessary to support this.
  43. * The Perfect Setup
  44. The Perfect Setup to hack on Guix is basically the perfect setup used
  45. for Guile hacking (info "(guile) Using Guile in Emacs"). First, you
  46. need more than an editor, you need [[http://www.gnu.org/software/emacs][Emacs]], empowered by the wonderful
  47. [[http://nongnu.org/geiser/][Geiser]].
  48. Geiser allows for interactive and incremental development from within
  49. Emacs: code compilation and evaluation from within buffers, access to
  50. on-line documentation (docstrings), context-sensitive completion, M-. to
  51. jump to an object definition, a REPL to try out your code, and more.
  52. To actually edit the code, Emacs already has a neat Scheme mode. But in
  53. addition to that, you must not miss [[http://www.emacswiki.org/emacs/ParEdit][Paredit]]. It provides facilities to
  54. directly operate on the syntax tree, such as raising an s-expression or
  55. wrapping it, swallowing or rejecting the following s-expression, etc.
  56. * Submitting Patches
  57. Development is done using the Git distributed version control system. Thus,
  58. access to the repository is not strictly necessary. We welcome contributions
  59. in the form of patches as produced by ‘git format-patch’ sent to
  60. 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
  61. format]]; you can check the commit history for examples.
  62. Before submitting a patch that adds or modifies a package definition, please
  63. run ‘guix lint PACKAGE’, where PACKAGE is the name of the new or modified
  64. package, and fix any errors it reports. In addition, please make sure the
  65. package builds on your platform, using ‘guix build’. You may also want to
  66. check that dependent package (if applicable) are not affected by the change;
  67. ‘guix refresh --list-dependent PACKAGE’ will help you do that.
  68. When posting a patch to the mailing list, use "[PATCH] ..." as a subject. You
  69. may use your email client or the ‘git send-mail’ command.
  70. As you become a regular contributor, you may find it convenient to have write
  71. access to the repository (see below.)
  72. * Coding Style
  73. In general our code follows the [[info:standards][GNU Coding Standards]] (GCS). However, the GCS
  74. do not say much about Scheme, so here are some additional rules.
  75. ** Programming Paradigm
  76. Scheme code in Guix is written in a purely functional style. One exception is
  77. code that involves input/output, and procedures that implement low-level
  78. concepts, such as the ‘memoize’ procedure.
  79. ** Modules
  80. Guile modules that are meant to be used on the builder side must live in the
  81. (guix build …) name space. They must not refer to other Guix or GNU modules.
  82. However, it is OK for a “host-side” module to use a build-side module.
  83. Modules that deal with the broader GNU system should be in the (gnu …) name
  84. space rather than (guix …).
  85. ** Data Types and Pattern Matching
  86. The tendency in classical Lisp is to use lists to represent everything, and
  87. then to browse them “by hand” using ‘car’, ‘cdr’, ‘cadr’, and co. There are
  88. several problems with that style, notably the fact that it is hard to read,
  89. error-prone, and a hindrance to proper type error reports.
  90. Guix code should define appropriate data types (for instance, using
  91. ‘define-record-type*’) rather than abuse lists. In addition, it should use
  92. pattern matching, via Guile’s (ice-9 match) module, especially when matching
  93. lists.
  94. ** Formatting Code
  95. When writing Scheme code, we follow common wisdom among Scheme programmers.
  96. In general, we follow the [[http://mumble.net/~campbell/scheme/style.txt][Riastradh's Lisp Style Rules]]. This document happens
  97. to describe the conventions mostly used in Guile’s code too. It is very
  98. thoughtful and well written, so please do read it.
  99. Some special forms introduced in Guix, such as the ‘substitute*’ macro, have
  100. special indentation rules. These are defined in the .dir-locals.el file,
  101. which Emacs automatically uses. If you do not use Emacs, please make sure to
  102. let your editor know the rules.
  103. We require all top-level procedures to carry a docstring. This requirement
  104. can be relaxed for simple private procedures in the (guix build …) name space,
  105. though.
  106. Procedures should not have more than four positional parameters. Use keyword
  107. parameters for procedures that take more than four parameters.
  108. * Commit Access
  109. For frequent contributors, having write access to the repository is
  110. convenient. When you deem it necessary, feel free to ask for it on the
  111. mailing list. When you get commit access, please make sure to follow the
  112. policy below (discussions of the policy can take place on guix-devel@gnu.org.)
  113. Non-trivial patches should always be posted to guix-devel@gnu.org (trivial
  114. patches include fixing typos, etc.)
  115. For patches that just add a new package, and a simple one, it’s OK to commit,
  116. if you’re confident (which means you successfully built it in a chroot setup,
  117. and have done a reasonable copyright and license auditing.) Likewise for
  118. package upgrades, except upgrades that trigger a lot of rebuilds (for example,
  119. upgrading GnuTLS or GLib.) We have a mailing list for commit notifications
  120. (guix-commits@gnu.org), so people can notice. Before pushing your changes,
  121. make sure to run ‘git pull --rebase’.
  122. For anything else, please post to guix-devel@gnu.org and leave time for a
  123. review, without committing anything. If you didn’t receive any reply
  124. after two weeks, and if you’re confident, it’s OK to commit.
  125. That last part is subject to being adjusted, allowing individuals to commit
  126. directly on non-controversial changes on parts they’re familiar with.