From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mathieu Lirzin Subject: [PATCH] doc: Merge 'HACKING' into Texinfo manual. Date: Tue, 09 Jun 2015 13:42:04 +0200 Message-ID: <87mw09xg4z.fsf@openmailbox.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43864) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2Hvx-0000om-R8 for guix-devel@gnu.org; Tue, 09 Jun 2015 07:43:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z2Hvo-0005JJ-SZ for guix-devel@gnu.org; Tue, 09 Jun 2015 07:43:09 -0400 Received: from smtp7.openmailbox.org ([62.4.1.41]:44473) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2Hvo-0005Fc-Bs for guix-devel@gnu.org; Tue, 09 Jun 2015 07:43:00 -0400 Received: from localhost (localhost [127.0.0.1]) by mail2.openmailbox.org (Postfix) with ESMTP id 5B10C202F77 for ; Tue, 9 Jun 2015 13:42:58 +0200 (CEST) Received: from mail2.openmailbox.org ([62.4.1.33]) by localhost (mail.openmailbox.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id oItNqnRlLALi for ; Tue, 9 Jun 2015 13:42:54 +0200 (CEST) List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: guix-devel@gnu.org --=-=-= Content-Type: text/plain Hello Guix, This patch will need an update when Alex recent patch (doc: Add 'help2man' to HACKING.) will be pushed. do 'HACKING' copyright notices need to be added to the manual too? -- Mathieu Lirzin --=-=-= Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename=0001-doc-Merge-HACKING-into-Texinfo-manual.patch Content-Transfer-Encoding: quoted-printable >From ccbbddb5d5335b3714a4e6204498f1fc24dca6ab Mon Sep 17 00:00:00 2001 From: Mathieu Lirzin Date: Tue, 9 Jun 2015 00:08:43 +0200 Subject: [PATCH] doc: Merge 'HACKING' into Texinfo manual. * HACKING: Delete file. (Building from Git, The Perfect Setup, Coding Style, Submitting Patches): Move to ... * doc/guix.texi (Running Guix Before It Is Installed): Likewise. (Contributing): ... here. * README (Installation): Adapt to it. * configure.ac (DOT): Likewise. * Makefile.am (EXTRA_DIST): Likewise. --- HACKING | 163 ------------------------------------- Makefile.am | 1 - README | 4 +- configure.ac | 2 +- doc/guix.texi | 254 +++++++++++++++++++++++++++++++++++++++++++++++-------= ---- 5 files changed, 212 insertions(+), 212 deletions(-) delete mode 100644 HACKING diff --git a/HACKING b/HACKING deleted file mode 100644 index cf10ba5..0000000 --- a/HACKING +++ /dev/null @@ -1,163 +0,0 @@ --*- mode: org; coding: utf-8; -*- - -#+TITLE: Hacking GNU Guix and Its Incredible Distro - -Copyright =C2=A9 2012, 2013, 2014, 2015 Ludovic Court=C3=A8s -Copyright =C2=A9 2013 Nikita Karetnikov -Copyright =C2=A9 2014 Pierre-Antoine Rault - - 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 =E2=80=98./bootstrap=E2=80=99 to download the Nix daemon source code a= nd 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=E2=80=99t find =E2=80=98pkg.m4=E2= =80=99, which is provided by -pkg-config. Make sure that =E2=80=98pkg.m4=E2=80=99 is available. For in= stance, if you -installed Automake in =E2=80=98/usr/local=E2=80=99, it wouldn=E2=80=99t lo= ok for =E2=80=98.m4=E2=80=99 files in -=E2=80=98/usr/share=E2=80=99. So you have to invoke the following command= in that case - - $ export ACLOCAL_PATH=3D/usr/share/aclocal - -See =E2=80=9Cinfo '(automake) Macro Search Path'=E2=80=9D for more informa= tion. - -Then, run =E2=80=98./configure=E2=80=99 as usual. - -Finally, you have to invoke =E2=80=98make check=E2=80=99 to run tests. If= anything fails, -take a look at =E2=80=9Cinfo '(guix) Installation'=E2=80=9D or send a mess= age to -. - -* Running Guix before it is installed - -See the same-named section in the manual. - -* 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][Em= acs]], 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/ParEd= it][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. - -* Submitting Patches - -Development is done using the Git distributed version control system. Thu= s, -access to the repository is not strictly necessary. We welcome contributi= ons -in the form of patches as produced by =E2=80=98git format-patch=E2=80=99 s= ent 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, plea= se -run =E2=80=98guix lint PACKAGE=E2=80=99, 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 =E2=80=98guix build=E2=80=99. You = may also want to -check that dependent package (if applicable) are not affected by the chang= e; -=E2=80=98guix refresh --list-dependent PACKAGE=E2=80=99 will help you do t= hat. - -When posting a patch to the mailing list, use "[PATCH] ..." as a subject. = You -may use your email client or the =E2=80=98git send-mail=E2=80=99 command. - -As you become a regular contributor, you may find it convenient to have wr= ite -access to the repository (see below.) - -* Coding Style - -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. - -** Programming Paradigm - -Scheme code in Guix is written in a purely functional style. One exceptio= n is -code that involves input/output, and procedures that implement low-level -concepts, such as the =E2=80=98memoize=E2=80=99 procedure. - -** Modules - -Guile modules that are meant to be used on the builder side must live in t= he -(guix build =E2=80=A6) name space. They must not refer to other Guix or G= NU modules. -However, it is OK for a =E2=80=9Chost-side=E2=80=9D module to use a build-= side module. - -Modules that deal with the broader GNU system should be in the (gnu =E2=80= =A6) name -space rather than (guix =E2=80=A6). - -** Data Types and Pattern Matching - -The tendency in classical Lisp is to use lists to represent everything, and -then to browse them =E2=80=9Cby hand=E2=80=9D using =E2=80=98car=E2=80=99,= =E2=80=98cdr=E2=80=99, =E2=80=98cadr=E2=80=99, 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 -=E2=80=98define-record-type*=E2=80=99) rather than abuse lists. In additi= on, it should use -pattern matching, via Guile=E2=80=99s (ice-9 match) module, especially whe= n matching -lists. - -** Formatting Code - -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=E2=80=99s code too. It i= s very -thoughtful and well written, so please do read it. - -Some special forms introduced in Guix, such as the =E2=80=98substitute*=E2= =80=99 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 =E2=80=A6)= name space, -though. - -Procedures should not have more than four positional parameters. Use keyw= ord -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 guix-devel@gnu.o= rg.) - -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=E2=80=99s OK= to commit, -if you=E2=80=99re confident (which means you successfully built it in a ch= root setup, -and have done a reasonable copyright and license auditing.) Likewise for -package upgrades, except upgrades that trigger a lot of rebuilds (for exam= ple, -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 =E2=80=98git pull --rebase=E2=80=99. - -For anything else, please post to guix-devel@gnu.org and leave time for a -review, without committing anything. If you didn=E2=80=99t receive any re= ply -after two weeks, and if you=E2=80=99re confident, it=E2=80=99s OK to commi= t. - -That last part is subject to being adjusted, allowing individuals to commit -directly on non-controversial changes on parts they=E2=80=99re familiar wi= th. diff --git a/Makefile.am b/Makefile.am index 6478aeb..3f458ff 100644 --- a/Makefile.am +++ b/Makefile.am @@ -249,7 +249,6 @@ dist_pkgdata_DATA =3D hydra.gnu.org.pub dist_bashcompletion_DATA =3D etc/completion/bash/guix =20 EXTRA_DIST =3D \ - HACKING \ ROADMAP \ TODO \ .dir-locals.el \ diff --git a/README b/README index 4d3367e..df52822 100644 --- a/README +++ b/README @@ -46,8 +46,8 @@ See the manual for the installation instructions, either = by running =20 or by checking the [[http://www.gnu.org/software/guix/manual/guix.html#Ins= tallation][web copy of the manual]]. =20 -For information on installation from a Git checkout, please see the =E2=80= =98HACKING=E2=80=99 -file. +For information on installation from a Git checkout, please see the section +"Building from Git" in the manual. =20 * Installing Guix from Guix =20 diff --git a/configure.ac b/configure.ac index 50b65fd..2c8b9f0 100644 --- a/configure.ac +++ b/configure.ac @@ -179,7 +179,7 @@ AC_CACHE_SAVE m4_include([config-daemon.ac]) =20 dnl `dot' (from the Graphviz package) is only needed for maintainers. -dnl See `HACKING' for more info. +dnl See `Building from Git' in the manual for more info. AM_MISSING_PROG([DOT], [dot]) =20 dnl Manual pages. diff --git a/doc/guix.texi b/doc/guix.texi index c62e44e..e9ee637 100644 --- a/doc/guix.texi +++ b/doc/guix.texi @@ -13,7 +13,8 @@ Copyright @copyright{} 2012, 2013, 2014, 2015 Ludovic Court=C3=A8s@* Copyright @copyright{} 2013, 2014 Andreas Enge@* Copyright @copyright{} 2013 Nikita Karetnikov@* -Copyright @copyright{} 2015 Taylan Ulrich Bay=C4=B1rl=C4=B1/Kammer +Copyright @copyright{} 2015 Taylan Ulrich Bay=C4=B1rl=C4=B1/Kammer@* +Copyright @copyright{} 2015 Mathieu Lirzin =20 Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or @@ -88,7 +89,6 @@ Installation * Running the Test Suite:: Testing Guix. * Setting Up the Daemon:: Preparing the build daemon's environment. * Invoking guix-daemon:: Running the build daemon. -* Running Guix Before It Is Installed:: Hacker tricks. =20 Setting Up the Daemon =20 @@ -253,7 +253,6 @@ instead, you want to install the complete GNU operating= system, * Running the Test Suite:: Testing Guix. * Setting Up the Daemon:: Preparing the build daemon's environment. * Invoking guix-daemon:: Running the build daemon. -* Running Guix Before It Is Installed:: Hacker tricks. @end menu =20 @node Binary Installation @@ -847,44 +846,6 @@ useful in exceptional circumstances, such as if you ne= ed to run several daemons on the same machine. @end table =20 -@node Running Guix Before It Is Installed -@section Running Guix Before It Is Installed - -If you are hacking Guix itself---which is a good idea!---you will find -it useful to test the changes made in your local source tree checkout -without actually installing them. - -To that end, all the command-line tools can be used even if you have not -run @command{make install}. To do that, prefix each command with -@command{./pre-inst-env} (the @file{pre-inst-env} script lives in the -top build tree of Guix), as in: - -@example -$ sudo ./pre-inst-env guix-daemon --build-users-group=3Dguixbuild -$ ./pre-inst-env guix build hello -@end example - -@noindent -Similarly, for a Guile session using the Guix modules: - -@example -$ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system= ))' -@end example - -The @command{pre-inst-env} script sets up all the environment variables -necessary to support this, including @code{PATH} and -@code{GUILE_LOAD_PATH}. - -If you are hacking Guix from Emacs using the wonderful Geiser -(@pxref{Introduction,,, geiser, Geiser User Manual}), make sure to -augment Guile's load path so that it finds source files from your -checkout: - -@lisp -;; Assuming the Guix checkout is in ~/src/guix. -(add-to-list 'geiser-guile-load-path "~/src/guix") -@end lisp - =20 @c ********************************************************************* @node Package Management @@ -6780,10 +6741,213 @@ grow! Please get in touch with us on @email{guix-= devel@@gnu.org} and reports, patches, and anything that may be helpful to the project. We particularly welcome help on packaging (@pxref{Packaging Guidelines}). =20 -Please see the -@url{http://git.savannah.gnu.org/cgit/guix.git/tree/HACKING, -@file{HACKING} file} that comes with the Guix source code for practical -details about contributions. +@menu +* Building from Git:: The latest and greatest. +* Running Guix Before It Is Installed:: Hacker tricks. +* The Perfect Setup:: The right tools. +* Coding Style:: Hygiene of the contributor. +* Submitting Patches:: Share your work. +@end menu + + +@node Building from Git +@section Building from Git + +If you want to hack Guix itself, it is recommended to use the latest +version from the Git repository. When building Guix from a checkout, +the following packages are required in addition to those mentioned in +the installation instructions (@pxref{Requirements}). + +@itemize +@item @url{http://gnu.org/software/autoconf/, GNU Autoconf}; +@item @url{http://gnu.org/software/automake/, GNU Automake}; +@item @url{http://gnu.org/software/gettext/, GNU Gettext}; +@item @url{http://www.graphviz.org/, Graphviz}. +@end itemize + +Run @command{./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. + +@noindent +If you get an error like this one: + +@example +configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES +@end example + +it probably means that Autoconf couldn=E2=80=99t find @file{pkg.m4}, which= is +provided by @command{pkg-config}. Make sure that @file{pkg.m4} is +available. For instance, if you installed Automake in +@file{/usr/local}, it wouldn=E2=80=99t look for @file{.m4} files in +@file{/usr/share}. So you have to invoke the following command in that +case + +@example +export ACLOCAL_PATH=3D/usr/share/aclocal +@end example + +See @pxref{Macro Search Path,,, automake, The GNU Automake Manual} for +more information. + +Then, run @command{./configure} as usual. + +Finally, you have to invoke @code{make check} to run tests. If anything +fails, take a look at installation instructions (@pxref{Installation}) +or send a message to the @email{guix-devel@@gnu.org, mailing list}. + + +@node Running Guix Before It Is Installed +@section Running Guix Before It Is Installed + +In order to keep a sane working environment, you will find it useful to +test the changes made in your local source tree checkout without +actually installing them. So that you can distinguish between your +``end-user'' hat and your ``motley'' costume. + +To that end, all the command-line tools can be used even if you have not +run @code{make install}. To do that, prefix each command with +@command{./pre-inst-env} (the @file{pre-inst-env} script lives in the +top build tree of Guix), as in: + +@example +$ sudo ./pre-inst-env guix-daemon --build-users-group=3Dguixbuild +$ ./pre-inst-env guix build hello +@end example + +@noindent +Similarly, for a Guile session using the Guix modules: + +@example +$ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system= ))' +@end example + +The @command{pre-inst-env} script sets up all the environment variables +necessary to support this, including @env{PATH} and @env{GUILE_LOAD_PATH}. + + +@node The Perfect Setup +@section The Perfect Setup + +The Perfect Setup to hack on Guix is basically the perfect setup used +for Guile hacking (@pxref{Using Guile in Emacs,,, guile, Guile Reference +Manual}). First, you need more than an editor, you need +@url{http://www.gnu.org/software/emacs, Emacs}, empowered by the +wonderful @url{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, +@kbd{M-.} to jump to an object definition, a REPL to try out your code, +and more (@pxref{Introduction,,, geiser, Geiser User Manual}). For +convenient Guix development, make sure to augment Guile=E2=80=99s load pat= h so +that it finds source files from your checkout: + +@lisp +;; @r{Assuming the Guix checkout is in ~/src/guix.} +(add-to-list 'geiser-guile-load-path "~/src/guix") +@end lisp + +To actually edit the code, Emacs already has a neat Scheme mode. But in +addition to that, you must not miss +@url{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. + + +@node Coding Style +@section Coding Style + +In general our code follows the GNU Coding Standards (@pxref{Top,,, +standards, GNU Coding Standards}). However, they do not say much about +Scheme, so here are some additional rules. + +@menu +* Programming Paradigm:: How to compose your elements. +* Modules:: Where to store your code? +* Data Types and Pattern Matching:: Implementing data structures. +* Formatting Code:: Writing conventions. +@end menu + +@node Programming Paradigm +@subsection Programming Paradigm + +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 @code{memoize} procedure. + +@node Modules +@subsection Modules + +Guile modules that are meant to be used on the builder side must live in +the @code{(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. + +Modules that deal with the broader GNU system should be in the +@code{(gnu ...)} name space rather than @code{(guix ...)}. + +@node Data Types and Pattern Matching +@subsection 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 @code{car}, @code{cdr}, +@code{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 +@code{define-record-type*}) rather than abuse lists. In addition, it +should use pattern matching, via Guile=E2=80=99s @code{(ice-9 match)} modu= le, +especially when matching lists. + +@node Formatting Code +@subsection Formatting Code + +When writing Scheme code, we follow common wisdom among Scheme +programmers. In general, we follow the +@url{http://mumble.net/~campbell/scheme/style.txt, Riastradh's Lisp +Style Rules}. This document happens to describe the conventions mostly +used in Guile=E2=80=99s code too. It is very thoughtful and well written,= so +please do read it. + +Some special forms introduced in Guix, such as the @code{substitute*} +macro, have special indentation rules. These are defined in the +@file{.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 +@code{(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. + + +@node Submitting Patches +@section 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 @code{git +format-patch} sent to the @email{guix-devel@@gnu.org, mailing list}. +Please write commit logs in the ChangeLog format (@pxref{Change Logs,,, +Standards, GNU Coding Standards}); you can check the commit history for +examples. + +Before submitting a patch that adds or modifies a package definition, +please run @code{guix lint @var{package}}, where @var{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 +@code{guix build @var{package}}. You may also want to check that +dependent package (if applicable) are not affected by the change; +@code{guix refresh --list-dependent @var{package}} will help you do +that. + +When posting a patch to the mailing list, use @samp{[PATCH] ...} as a +subject. You may use your email client or the @command{git send-mail} +command. =20 =20 @c ********************************************************************* --=20 2.1.4 --=-=-=--