This chapter should walk you through the steps necessary to build darcs for yourself. There are in general two ways to build darcs. One is for building released versions from tarballs, and the other is to build the latest and greatest darcs, from the darcs repo itself.
Please let me know if you have any problems building darcs, or don't have problems described in this chapter and think there's something obsolete here, so I can keep this page up-to-date.
It is a good idea (but not required) to have software installed that provide darcs network access. The libwww-dev, libwww-ssl-dev or libcurl packages newer than than 7.18.0 are recommended because they provide pipelining support speed up HTTP access. They have to explicitly chosen with -with-libwww or -with-curl-pipelining. Otherwise, darcs will automatically look for one of libcurl, curl or wget. You also might want to have scp available if you want to grab your repos over ssh...
To use the diff
command of darcs, a diff
program supporting
options -r
(recursive diff) and -N
(show new files as
differences against an empty file) is required. The configure
script will look for gdiff
, gnudiff
and diff
in this
order. You can force the use of another program by setting the DIFF
environment variable before running configure
.
To rebuild the documentation (which should not be necessary since it is included in html form with the tarballs), you will need to have latex installed, as well as latex2html if you want to build it in html form.
Copy the zlib and curl libraries and headers to both GHC and MinGW. GHC
stores C headers in <ghc-dir>/gcc-lib/include
and libraries in
<ghc-dir>/gcc-lib
. MinGW stores headers in
<mingw-dir>/include
and libraries in <mingw-dir>/lib
.
Set PATH to include the <msys-dir>/bin
, <mingw-dir>/bin
,
<curl-dir>
, and a directory containing a pre-built darcs.exe if you
want the build's patch context stored for `darcs --exact-version
'.
C:\darcs> cd <darcs-source-dir> C:\darcs> sh $ export GHC=/c/<ghc-dir>/bin/ghc.exe $ autoconf $ ./configure --target=mingw $ make
% ./configure % make # Optional, but recommended % make test % make install
There are options to configure that you may want to check out with
% ./configure --help
If your header files are installed in a non-standard location, you may need
to define the CFLAGS
and CPPFLAGS
environment variables to
include the path to the headers. e.g. on NetBSD, you may need to run
% CFLAGS=-I/usr/pkg/include CPPFLAGS=-I/usr/pkg/include ./configure
% darcs get -v http://darcs.net/and once you have the darcs repository you can bring it up to date with a
% darcs pull
The repository doesn't hold automatically generated files, which include
the configure script and the HTML documentation, so you need to run
autoconf
first.
You'll need autoconf
2.50 or higher. Some systems have more than one
version of autoconf
installed. For example, autoconf
may point to
version 2.13, while autoconf259
runs version 2.59.
Also note that make
is really "GNU make". On some systems, such as
the *BSDs, you may need to type gmake
instead of make for this to work.
If you want to create readable documentation you'll need to have latex installed.
% autoconf % ./configure % make % make install
If you want to tweak the configure options, you'll need to run ./configure yourself after the make, and then run make again.
To enable git support, you first need to grab a copy of the git
source code; since darcs doesn't yet have the capability of accessing
remote git repositories, you'll have to either download a tarball or use
git itself to clone a git repository. Compile git (no need to
install); this will create a file ``libgit.a
''. Then create a
symlink to the git source directory named ``git
'' in your darcs
source directory, configure darcs using the ``--enable-git
''
option, and build darcs as usual.
building_darcs.tex
) based
on your experience building darcs...
To do so, just record your changes (which you made in the darcs repository)
% darcs record --no-testmaking sure to give the patch a nice descriptive name. The
--no-test
options keeps darcs from trying to run the unit tests,
which can be rather time-consuming. Then you can send the patch to the
darcs-devel mailing list by email by
% darcs send -uThe darcs repository stores the email address to which patches should be sent by default. The email address you see is actually my own, but when darcs notices that you haven't signed the patch with my GPG key, it will forward the message to darcs-devel.
darcs-stable 2008-04-09