Merge pull request #5870 from fgaz/new-install/bindir-method
[cabal.git] / README.md
blobffb36d3ea4c62d7314c6985bade4dc8a2ece1941
1 # Cabal [![Hackage version](https://img.shields.io/hackage/v/Cabal.svg?label=Hackage)](https://hackage.haskell.org/package/Cabal) [![Stackage version](https://www.stackage.org/package/Cabal/badge/lts?label=Stackage)](https://www.stackage.org/package/Cabal) [![Build Status](https://secure.travis-ci.org/haskell/cabal.svg?branch=master)](http://travis-ci.org/haskell/cabal) [![Windows build status](https://ci.appveyor.com/api/projects/status/github/haskell/cabal?branch=master&svg=true)](https://ci.appveyor.com/project/23Skidoo/cabal) [![Documentation Status](http://readthedocs.org/projects/cabal/badge/?version=latest)](http://cabal.readthedocs.io/en/latest/?badge=latest)
3 This Cabal Git repository contains the following packages:
5  * [Cabal](Cabal/README.md): the Cabal library package ([license](Cabal/LICENSE))
6  * [cabal-install](cabal-install/README.md): the package containing the `cabal` tool ([license](cabal-install/LICENSE))
8 The canonical upstream repository is located at
9 https://github.com/haskell/cabal.
11 Installing Cabal (by downloading the binary)
12 --------------------------------------------
14 Prebuilt binary releases can be obtained from https://www.haskell.org/cabal/download.html.
15 The `cabal-install` binary download for your platform should contain the `cabal` executable.
17 Installing Cabal (with cabal)
18 -----------------------------
20 Assuming that you have a pre-existing, older version of `cabal-install`,
21 run:
23 ~~~~
24 cabal install cabal-install
25 ~~~~
27 To get the latest version of `cabal-install`. (You may want to `cabal
28 update` first.)
30 To install the latest version from the Git repository, clone the
31 Git repository and then run:
33 ~~~~
34 (cd Cabal; cabal install)
35 (cd cabal-install; cabal install)
36 ~~~~
38 Installing Cabal (without cabal)
39 --------------------------------
41 Assuming you don't have a pre-existing copy of `cabal-install`, run:
43 ~~~~
44 cabal-install $ ./bootstrap.sh # running ./bootstrap.sh from within in cabal-install folder.
45 ~~~~
47 For more details, and non-unix like systems, see the [README.md in cabal-install](cabal-install/README.md)
49 Building Cabal for hacking
50 --------------------------
52 The current recommended way of developing Cabal is to use the
53 `new-build` feature which [shipped in cabal-install-1.24](http://blog.ezyang.com/2016/05/announcing-cabal-new-build-nix-style-local-builds/).  Assuming
54 that you have a sufficiently recent cabal-install (see above),
55 it is sufficient to run:
57 ~~~~
58 cabal new-build cabal
59 ~~~~
61 To build a local, development copy of cabal-install.  The location
62 of your build products will vary depending on which version of
63 cabal-install you use to build; see the documentation section
64 [Where are my build products?](http://cabal.readthedocs.io/en/latest/nix-local-build.html#where-are-my-build-products)
65 to find the binary (or just run `find -type f -executable -name cabal`).
67 Here are some other useful variations on the commands:
69 ~~~~
70 cabal new-build Cabal # build library only
71 cabal new-build Cabal:unit-tests # build Cabal's unit test suite
72 cabal new-build cabal-tests # etc...
73 ~~~~
75 **Dogfooding HEAD.**
76 Many of the core developers of Cabal dogfood `cabal-install` HEAD
77 when doing development on Cabal.  This helps us identify bugs
78 which were missed by the test suite and easily experiment with new
79 features.
81 The recommended workflow in this case is slightly different: you will
82 maintain two Cabal source trees: your production tree (built with a
83 released version of Cabal) which always tracks `master` and which you
84 update only when you want to move to a new version of Cabal to dogfood,
85 and your development tree (built with your production Cabal) that you
86 actually do development on.
88 In more detail, suppose you have checkouts of Cabal at `~/cabal-prod`
89 and `~/cabal-dev`, and you have a release copy of cabal installed at
90 `/opt/cabal/2.4/bin/cabal`.  First, build your production tree:
92 ~~~~
93 cd ~/cabal-prod
94 /opt/cabal/2.4/bin/cabal new-build cabal
95 ~~~~
97 This will produce a cabal binary (see also: [Where are my build products?](http://cabal.readthedocs.io/en/latest/nix-local-build.html#where-are-my-build-products)
98 ).  Add this binary to your PATH,
99 and then use it to build your development copy:
101 ~~~~
102 cd ~/cabal-dev
103 cabal new-build cabal
104 ~~~~
106 Running tests
107 -------------
109 **Using Travis and AppVeyor.**
110 If you are not in a hurry, the most convenient way to run tests on Cabal
111 is to make a branch on GitHub and then open a pull request; our
112 continuous integration service on Travis and AppVeyor will build and
113 test your code.  Title your PR with WIP so we know that it does not need
114 code review.
116 Some tips for using Travis effectively:
118 * Travis builds take a long time.  Use them when you are pretty
119   sure everything is OK; otherwise, try to run relevant tests locally
120   first.
122 * Watch over your jobs on the [Travis website](http://travis-ci.org).
123   If you know a build of yours is going to fail (because one job has
124   already failed), be nice to others and cancel the rest of the jobs,
125   so that other commits on the build queue can be processed.
127 * If you want realtime notification when builds of your PRs finish, we have a [Slack team](https://haskell-cabal.slack.com/). To get issued an invite, fill in your email at [this sign up page](https://haskell-cabal.herokuapp.com).
129 **How to debug a failing CI test.**
130 One of the annoying things about running tests on CI is when they
131 fail, there is often no easy way to further troubleshoot the broken
132 build.  Here are some guidelines for debugging continuous integration
133 failures:
135 1. Can you tell what the problem is by looking at the logs?  The
136    `cabal-testsuite` tests run with `-v` logging by default, which
137    is dumped to the log upon failure; you may be able to figure out
138    what the problem is directly this way.
140 2. Can you reproduce the problem by running the test locally?
141    See the next section for how to run the various test suites
142    on your local machine.
144 3. Is the test failing only for a specific version of GHC, or
145    a specific operating system?  If so, try reproducing the
146    problem on the specific configuration.
148 4. Is the test failing on a Travis per-GHC build
149    ([for example](https://travis-ci.org/haskell-pushbot/cabal-binaries/builds/208128401))?
150    In this case, if you click on "Branch", you can get access to
151    the precise binaries that were built by Travis that are being
152    tested.  If you have an Ubuntu system, you can download
153    the binaries and run them directly.
155 5. Is the test failing on AppVeyor?  Consider logging in via
156    Remote Desktop to the build VM:
157    https://www.appveyor.com/docs/how-to/rdp-to-build-worker/
159 If none of these let you reproduce, there might be some race condition
160 or continuous integration breakage; please file a bug.
162 **Running tests locally.**
163 To run tests locally with `new-build`, you will need to know the
164 name of the test suite you want.  Cabal and cabal-install have
165 several.  Also, you'll want to read [Where are my build products?](http://cabal.readthedocs.io/en/latest/nix-local-build.html#where-are-my-build-products)
167 The most important test suite is `cabal-testsuite`: most user-visible
168 changes to Cabal should come with a test in this framework.  See
169 [cabal-testsuite/README.md](cabal-testsuite/README.md) for more
170 information about how to run tests and write new ones.  Quick
171 start: use `cabal-tests` to run `Cabal` tests, and `cabal-tests
172 --with-cabal=/path/to/cabal` to run `cabal-install` tests
173 (don't forget `--with-cabal`! Your cabal-install tests won't
174 run without it).
176 There are also other test suites:
178 * `Cabal:unit-tests` are small, quick-running unit tests
179   on small pieces of functionality in Cabal.  If you are working
180   on some utility functions in the Cabal library you should run this
181   test suite.
183 * `cabal-install:unit-tests` are small, quick-running unit tests on
184   small pieces of functionality in cabal-install.  If you are working
185   on some utility functions in cabal-install you should run this test
186   suite.
188 * `cabal-install:solver-quickcheck` are QuickCheck tests on
189   cabal-install's dependency solver.  If you are working
190   on the solver you should run this test suite.
192 * `cabal-install:integration-tests2` are integration tests on some
193   top-level API functions inside the `cabal-install` source code.
195 For these test executables, `-p` which applies a regex filter to the test
196 names.
198 Conventions
199 -----------
201 * Spaces, not tabs.
203 * Try to follow style conventions of a file you are modifying, and
204   avoid gratuitous reformatting (it makes merges harder!)
206 * Format your commit messages [in the standard way](https://chris.beams.io/posts/git-commit/#seven-rules).
208 * A lot of Cabal does not have top-level comments.  We are trying to
209   fix this.  If you add new top-level definitions, please Haddock them;
210   and if you spend some time understanding what a function does, help
211   us out and add a comment.  We'll try to remind you during code review.
213 * If you do something tricky or non-obvious, add a comment.
215 * If your commit only touches comments, you can use `[ci skip]`
216   anywhere in the body of the commit message to avoid needlessly
217   triggering the build bots.
219 * For local imports (Cabal module importing Cabal module), import lists
220   are NOT required (although you may use them at your discretion.)  For
221   third-party and standard library imports, please use either qualified imports
222   or explicit import lists.
224 * You can use basically any GHC extension supported by a GHC in our
225   support window, except Template Haskell, which would cause
226   bootstrapping problems in the GHC compilation process.
228 * Our GHC support window is five years for the Cabal library and three
229   years for cabal-install: that is, the Cabal library must be
230   buildable out-of-the-box with the dependencies that shipped with GHC
231   for at least five years.  The Travis CI checks this, so most
232   developers submit a PR to see if their code works on all these
233   versions of GHC.  `cabal-install` must also be buildable on all
234   supported GHCs, although it does not have to be buildable
235   out-of-the-box. Instead, the `cabal-install/bootstrap.sh` script
236   must be able to download and install all of the dependencies (this
237   is also checked by CI). Also, self-upgrade to the latest version
238   (i.e. `cabal install cabal-install`) must work with all versions of
239   `cabal-install` released during the last three years.
241 * `Cabal` has its own Prelude, in `Distribution.Compat.Prelude`,
242   that provides a compatibility layer and exports some commonly
243   used additional functions. Use it in all new modules.
245 * As far as possible, please do not use CPP. If you must use it,
246   try to put it in a `Compat` module, and minimize the amount of code
247   that is enclosed by CPP.  For example, prefer:
248   ```
249   f :: Int -> Int
250   #ifdef mingw32_HOST_OS
251   f = (+1)
252   #else
253   f = (+2)
254   #endif
255   ```
257   over:
258   ```
259   #ifdef mingw32_HOST_OS
260   f :: Int -> Int
261   f = (+1)
262   #else
263   f :: Int -> Int
264   f = (+2)
265   #endif
266   ```
268 We like [this style guide][guide].
270 [guide]: https://github.com/tibbe/haskell-style-guide/blob/master/haskell-style.md
272 Communicating
273 -------------
275 There are a few main venues of communication:
277 * Most developers subscribe to receive messages from [all issues](https://github.com/haskell/cabal/issues); issues can be used to [open discussion](https://github.com/haskell/cabal/issues?q=is%3Aissue+is%3Aopen+custom+label%3A%22type%3A+discussion%22).  If you know someone who should hear about a message, CC them explicitly using the @username GitHub syntax.
279 * For more organizational concerns, the [mailing
280   list](http://www.haskell.org/mailman/listinfo/cabal-devel) is used.
282 * Many developers idle on `#hackage` on `irc.freenode.net` ([archives](http://ircbrowse.net/browse/hackage)).  `#ghc` ([archives](http://ircbrowse.net/browse/ghc)) is also a decently good bet.
284 Releases
285 --------
287 Notes for how to make a release are at the
288 wiki page ["Making a release"](https://github.com/haskell/cabal/wiki/Making-a-release).
289 Currently, @23Skidoo, @rthomas, @tibbe and @dcoutts have access to
290 `haskell.org/cabal`, and @davean is the point of contact for getting
291 permissions.
293 API Documentation
294 -----------------
296 Auto-generated API documentation for the `master` branch of Cabal is automatically uploaded here: http://haskell.github.io/cabal-website/doc/html/Cabal/.