all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
blob 8f6e835fbb3c27d3937e679047862ec8d8350522 6067 bytes (raw)
name: HACKING 	 # note: path name is non-authoritative(*)

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
 
-*- mode: org; coding: utf-8; -*-

#+TITLE: Hacking GNU Guix and Its Incredible Distro

Copyright © 2012, 2013 Ludovic Courtès <ludo@gnu.org>
Copyright © 2013 Nikita Karetnikov <nikita@karetnikov.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.


* Building from Git

The following errors might appear if you are building from Git.  Also,
take a look at the [[https://gnu.org/software/guix/manual/guix.html#Installation]["Installation"]] section of the manual and the
[[http://git.savannah.gnu.org/cgit/guix.git/tree/README]["Installing Guix from Guix"]] section in 'README'.

** ./configure: line 6755: `PKG_CHECK_MODULES(GUILE, guile-2.0 >= 2.0.5)'

This message means that Autoconf didn't pick up the definition of the
'PKG_CHECK_MODULES' M4 macro.  'pkg.m4' is provided by the 'pkg-config'
package.  If you install 'pkg-config', Autoconf should automatically find it.

However, if you installed Automake in '/usr/local', it wouldn't look for '.m4'
files in '/usr/share'.  You have to invoke the following command in that case:

  $ export ACLOCAL_PATH=/usr/share/aclocal

** make: *** No rule to make target `nix/libstore/schema.sql', needed by
`nix/libstore/schema.sql.hh'.

You must run './bootstrap', which invokes 'git submodule update', before
'./configure && make && make check'.

** /bin/bash: dot: command not found
make[2]: *** [doc/images/bootstrap-graph.png] Error 127

You must install Graphviz.  (It is not listed as a requirement because the
resulting images will be shipped with a tarball.)

* Running Guix before it is installed

Command-line tools can be used even if you have not run "make install".
To do that, prefix each command with ‘./pre-inst-env’, as in:

  ./pre-inst-env guix build --help

Similarly, for a Guile session using the Guix modules:

  ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))'

The ‘pre-inst-env’ script sets up all the environment variables
necessary to support this.

* 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.

* Adding new packages

Package recipes in Guix look like this:

#+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

Such a recipe can be written by hand, and then tested by running
‘./pre-inst-env guix build nettle’.

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:

  guix download http://ftp.gnu.org/gnu/nettle/nettle-2.5.tar.gz

Alternatively, it is possible to semi-automatically import recipes from
the [[http://nixos.org/nixpkgs/][Nixpkgs]] software distribution using this command:

  guix import /path/to/nixpkgs/checkout nettle

The command automatically fetches and converts to Guix the “Nix
expression” of Nettle.

* 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
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]].

As you become a regular contributor, you may find it convenient to have write
access to the repository (see below.)

* 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.)

Non-trivial patches should always be posted to bug-guix@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
(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
review, without committing anything.  If you didn’t receive any reply
after two weeks, and if you’re confident, it’s OK to commit.

That last part is subject to being adjusted, allowing individuals to commit
directly on non-controversial changes on parts they’re familiar with.

debug log:

solving 8f6e835 ...
found 8f6e835 in https://yhetil.org/guix/87ppuq2a7u.fsf@karetnikov.org/
found 9d8960c in https://git.savannah.gnu.org/cgit/guix.git
preparing index
index prepared:
100644 9d8960c1aba39ed068847cd009ec985e10eb372e	HACKING

applying [1/1] https://yhetil.org/guix/87ppuq2a7u.fsf@karetnikov.org/
diff --git a/HACKING b/HACKING
index 9d8960c..8f6e835 100644

Checking patch HACKING...
Applied patch HACKING cleanly.

index at:
100644 8f6e835fbb3c27d3937e679047862ec8d8350522	HACKING

(*) Git path names are given by the tree(s) the blob belongs to.
    Blobs themselves have no identifier aside from the hash of its contents.^

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.