Commit | Line | Data |
---|---|---|
450ccdc3 LC |
1 | -*- mode: org; coding: utf-8; -*- |
2 | ||
08ba7ff3 | 3 | #+TITLE: Hacking GNU Guix and Its Incredible Distro |
450ccdc3 | 4 | |
9149f1a0 | 5 | Copyright © 2012, 2013 Ludovic Courtès <ludo@gnu.org> |
450ccdc3 LC |
6 | |
7 | Copying and distribution of this file, with or without modification, | |
8 | are permitted in any medium without royalty provided the copyright | |
9 | notice and this notice are preserved. | |
10 | ||
11 | ||
08ba7ff3 LC |
12 | * Running Guix before it is installed |
13 | ||
14 | Command-line tools can be used even if you have not run "make install". | |
15 | To do that, prefix each command with ‘./pre-inst-env’, as in: | |
16 | ||
17 | ./pre-inst-env guix-build --help | |
18 | ||
19 | Similarly, for a Guile session using the Guix modules: | |
20 | ||
21 | ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))' | |
22 | ||
23 | The ‘pre-inst-env’ script sets up all the environment variables | |
24 | necessary to support this. | |
25 | ||
c6dbd505 LC |
26 | * The Perfect Setup |
27 | ||
28 | The Perfect Setup to hack on Guix is basically the perfect setup used | |
29 | for Guile hacking (info "(guile) Using Guile in Emacs"). First, you | |
30 | need more than an editor, you need [[http://www.gnu.org/software/emacs][Emacs]], empowered by the wonderful | |
31 | [[http://nongnu.org/geiser/][Geiser]]. | |
32 | ||
33 | Geiser allows for interactive and incremental development from within | |
34 | Emacs: code compilation and evaluation from within buffers, access to | |
35 | on-line documentation (docstrings), context-sensitive completion, M-. to | |
36 | jump to an object definition, a REPL to try out your code, and more. | |
37 | ||
38 | To actually edit the code, Emacs already has a neat Scheme mode. But in | |
39 | addition to that, you must not miss [[http://www.emacswiki.org/emacs/ParEdit][Paredit]]. It provides facilities to | |
40 | directly operate on the syntax tree, such as raising an s-expression or | |
41 | wrapping it, swallowing or rejecting the following s-expression, etc. | |
42 | ||
59b775cc LC |
43 | * Adding new packages |
44 | ||
45 | Package recipes in Guix look like this: | |
46 | ||
47 | #+BEGIN_SRC scheme | |
48 | (package | |
49 | (name "nettle") | |
50 | (version "2.5") | |
51 | (source | |
52 | (origin | |
3dc1970d LC |
53 | (method url-fetch) |
54 | (uri (string-append "mirror://gnu/nettle/nettle-" | |
59b775cc LC |
55 | version ".tar.gz")) |
56 | (sha256 | |
57 | (base32 | |
58 | "0wicr7amx01l03rm0pzgr1qvw3f9blaw17vjsy1301dh13ll58aa")))) | |
59 | (build-system gnu-build-system) | |
08ba7ff3 | 60 | (inputs `(("m4" ,m4))) |
59b775cc LC |
61 | (propagated-inputs `(("gmp" ,gmp))) |
62 | (home-page | |
63 | "http://www.lysator.liu.se/~nisse/nettle/") | |
64 | (synopsis "GNU Nettle, a cryptographic library") | |
65 | (description | |
66 | "Nettle is a cryptographic library...") | |
08ba7ff3 | 67 | (license gpl2+)) |
59b775cc LC |
68 | #+END_SRC |
69 | ||
70 | Such a recipe can be written by hand, and then tested by running | |
71 | ‘./pre-inst-env guix-build nettle’. | |
72 | ||
73 | When writing the recipe, the base32-encoded SHA256 hash of the source | |
74 | code tarball, which can be seen in the example above, can be obtained by | |
75 | running: | |
76 | ||
77 | guix-download http://ftp.gnu.org/gnu/nettle/nettle-2.5.tar.gz | |
78 | ||
79 | Alternatively, it is possible to semi-automatically import recipes from | |
80 | the [[http://nixos.org/nixpkgs/][Nixpkgs]] software distribution using this command: | |
81 | ||
82 | guix-import /path/to/nixpkgs/checkout nettle | |
83 | ||
84 | The command automatically fetches and converts to Guix the “Nix | |
85 | expression” of Nettle. | |
86 | ||
450ccdc3 LC |
87 | * Porting the Guix distro on a new platform |
88 | ||
89 | ** Introduction | |
90 | ||
91 | Unlike Make or similar build tools, Guix requires absolutely /all/ the | |
92 | dependencies of a build process to be specified. | |
93 | ||
94 | For a user-land software distribution, that means that the process that | |
95 | builds GCC (then used to build all other programs) must itself be | |
96 | specified; and the process to build the C library to build that GCC; and | |
97 | the process to build the GCC to build that library; and... See the | |
98 | problem? Chicken-and-egg. | |
99 | ||
100 | To break that cycle, the distro starts from a set of pre-built | |
101 | binaries–usually referred to as “bootstrap binaries.” These include | |
102 | statically-linked versions of Guile, GCC, Coreutils, Make, Grep, sed, | |
103 | etc., and the GNU C Library. | |
104 | ||
105 | This section describes how to build those bootstrap binaries when | |
106 | porting to a new platform. | |
107 | ||
108 | ** When the platform is supported by Nixpkgs | |
109 | ||
110 | In that case, the easiest thing is to bootstrap the distro using | |
111 | binaries from Nixpkgs. | |
112 | ||
113 | To do that, you need to comment out the definitions of | |
18633d4f | 114 | ‘%bootstrap-guile’ and ‘%bootstrap-inputs’ in distro/packages/bootstrap.scm |
450ccdc3 LC |
115 | to force the use of Nixpkgs derivations. For instance, when porting to |
116 | ‘i686-linux’, you should redefine these variables along these lines: | |
117 | ||
118 | #+BEGIN_SRC scheme | |
119 | (define %bootstrap-guile | |
120 | (nixpkgs-derivation "guile" "i686-linux")) | |
121 | ||
122 | (define %bootstrap-inputs | |
123 | (compile-time-value | |
124 | `(("libc" ,(nixpkgs-derivation "glibc" "i686-linux")) | |
125 | ,@(map (lambda (name) | |
126 | (list name (nixpkgs-derivation name "i686-linux"))) | |
127 | '("gnutar" "gzip" "bzip2" "xz" "patch" | |
128 | "coreutils" "gnused" "gnugrep" "bash" | |
129 | "gawk" ; used by `config.status' | |
130 | "gcc" "binutils"))))) | |
131 | #+END_SRC | |
132 | ||
133 | That should allow the distro to be bootstrapped. | |
134 | ||
135 | Then, the tarballs containing the initial binaries of Guile, Coreutils, | |
136 | GCC, libc, etc. need to be built. To that end, run the following | |
137 | commands: | |
138 | ||
139 | #+BEGIN_SRC sh | |
e1f8f477 NK |
140 | ./pre-inst-env guix-build -K \ |
141 | -e '(@ (gnu packages make-bootstrap) %bootstrap-tarballs)' \ | |
450ccdc3 | 142 | --system=i686-linux |
9149f1a0 | 143 | |
450ccdc3 LC |
144 | #+END_SRC |
145 | ||
146 | These should build tarballs containing statically-linked tools usable on | |
147 | that system. | |
148 | ||
149 | In the source tree, you need to install binaries for ‘mkdir’, ‘bash’, | |
150 | ‘tar’, and ‘xz’ under ‘distro/packages/bootstrap/i686-linux’. These | |
151 | binaries can be extracted from the static-binaries tarball built above. | |
152 | ||
9149f1a0 | 153 | A rule for ‘distro/packages/bootstrap/i686-linux/guile-2.0.7.tar.xz’ |
450ccdc3 LC |
154 | needs to be added in ‘Makefile.am’, with the appropriate hexadecimal |
155 | vrepresentation of its SHA256 hash. | |
156 | ||
9149f1a0 | 157 | You may then revert your changes to ‘bootstrap.scm’. For the variables |
450ccdc3 LC |
158 | ‘%bootstrap-coreutils&co’, ‘%bootstrap-binutils’, ‘%bootstrap-glibc’, |
159 | and ‘%bootstrap-gcc’, the expected SHA256 of the corresponding tarballs | |
160 | for ‘i686-linux’ (built above) must be added. | |
161 | ||
162 | This should be enough to bootstrap the distro without resorting to | |
163 | Nixpkgs. | |
164 | ||
165 | ** When the platform is *not* supported by Nixpkgs | |
166 | ||
167 | In that case, the bootstrap binaries should be built using whatever | |
168 | tools are available on the target platform. That is, the tarballs and | |
169 | binaries show above must first be built manually, using the available | |
170 | tools. | |
171 | ||
172 | They should have the same properties as those built by the Guix recipes | |
173 | shown above. For example, all the binaries (except for glibc) must be | |
174 | statically-linked; the bootstrap Guile must be relocatable (see patch in | |
175 | the Guix distro); the static-binaries tarball must contain the same | |
176 | programs (Coreutils, Grep, sed, Awk, etc.); and so on. | |
177 | ||
f5fd4360 LC |
178 | * Commit Access |
179 | ||
180 | Development is done using the Git distributed version control system. Thus, | |
181 | access to the repository is not strictly necessary. We welcome contributions | |
182 | in the form of patches as produced by ‘git format-patch’ sent to | |
183 | bug-guix@gnu.org. | |
184 | ||
185 | However, for frequent contributors, having write access to the repository is | |
186 | convenient. When you get commit access, please make sure to follow the policy | |
187 | below (discussions of the policy can take place on bug-guix@gnu.org.) | |
188 | ||
189 | Non-trivial patches should always be posted to bug-guix@gnu.org (trivial | |
190 | patches include fixing typos, etc.) | |
191 | ||
192 | For patches that just add a new package, and a simple one, it’s OK to commit, | |
193 | if you’re confident (which means you successfully built it in a chroot setup.) | |
194 | Likewise for package upgrades. We have a mailing list for commit | |
195 | notifications (guix-commits@gnu.org), so people can notice. Before pushing | |
196 | your changes, make sure to run ‘git pull --rebase’. | |
197 | ||
198 | For anything else, please post to bug-guix@gnu.org and leave time for a | |
199 | review, without committing anything. If you didn’t receive any reply | |
200 | after two weeks, and if you’re confident, it’s OK to commit. | |
201 | ||
202 | That last part is subject to being adjusted, allowing individuals to commit | |
203 | directly on non-controversial changes on parts they’re familiar with. |