Commit da58edd9 authored by Iustin Pop's avatar Iustin Pop
Browse files

Fix a number of typos in the documentation

While reading the docs, I saw a few typos, so I ran ispell through the
docs. Fixed:

- plain typos
- a few instances of 'ie'→'i.e.' and 'eg' → 'e.g.' for nicer style
- a few capitalisation issues (linux, unix)
- a few not-nice (IMHO) abbreviations (for a manual, that is):
  distro→distribution, repo→repository
- proper naming (RedHat→Red Hat)
parent db18c957
......@@ -349,7 +349,7 @@ automatic package management. This means tools like `cabal` can resolve
dependencies and install a package plus all of its dependencies
automatically. Alternatively, it is possible to mechanically (or mostly
mechanically) translate Cabal packages into system packages and let the
system package managager install dependencies automatically.
system package manager install dependencies automatically.
It is important to track dependencies accurately so that packages can
reliably be moved from one system to another system and still be able to
......@@ -362,15 +362,15 @@ could cause the code to fail to build on some other system.
The explicit dependency approach is in contrast to the traditional
"./configure" approach where instead of specifying dependencies
declarativly, the `./configure` script checks if the dependencies are
declaratively, the `./configure` script checks if the dependencies are
present on the system. Some manual work is required to transform a
`./configure` based package into a Linux distribution package (or
similar). This conversion work is usually done by people other than the
package author(s). The practical effect of this is that only the most
popular packages will benefit from automatic package managment. Instead,
popular packages will benefit from automatic package management. Instead,
Cabal forces the original author to specify the dependencies but the
advantage is that every package can benefit from automatic package
managment.
management.
The "./configure" approach tends to encourage packages that adapt
themselves to the environment in which they are built, for example by
......@@ -378,7 +378,7 @@ disabling optional features so that they can continue to work when a
particular dependency is not available. This approach makes sense in a
world where installing additional dependencies is a tiresome manual
process and so minimising dependencies is important. The automatic
package managment view is that packages should just declare what they
package management view is that packages should just declare what they
need and the package manager will take responsibility for ensuring that
all the dependencies are installed.
......@@ -417,7 +417,7 @@ that are needed and the build system will take care of using the right
flags for the compiler. Additionally this makes it easier for tools to
discover what system C libraries a package needs, which is useful for
tracking dependencies on system libraries (e.g. when translating into
linux distro packages).
Linux distribution packages).
In fact both of these examples fall into the category of explicitly
specifying dependencies. Not all dependencies are other Cabal packages.
......@@ -447,7 +447,7 @@ very well; if the executables depend on the library, they must
explicitly list all the modules they directly or indirectly import from
that library. Fortunately, starting with Cabal 1.8.0.4, executables can
also declare the package that they are in as a dependency, and Cabal
will treat them as if they were in another package that dependended on
will treat them as if they were in another package that depended on
the library.
Internally, the package may consist of much more than a bunch of Haskell
......@@ -730,7 +730,7 @@ describe the package as a whole:
`cabal-version:` _>= x.y_
: The version of the Cabal specification that this package description uses.
The Cabal specification does slowly evolve, intoducing new features and
The Cabal specification does slowly evolve, introducing new features and
occasionally changing the meaning of existing features. By specifying
which version of the spec you are using it enables programs which process
the package description to know what syntax to expect and what each part
......@@ -741,8 +741,8 @@ describe the package as a whole:
bounds do not make sense. In future this field will specify just a version
number, rather than a version range.
The version number you specify will affect both compatability and
behaviour. Most tools (including the Cabal libray and cabal program)
The version number you specify will affect both compatibility and
behaviour. Most tools (including the Cabal library and cabal program)
understand a range of versions of the Cabal specification. Older tools
will of course only work with older versions of the Cabal specification.
Most of the time, tools that are too old will recognise this fact and
......@@ -757,7 +757,7 @@ describe the package as a whole:
In particular, the syntax of package descriptions changed significantly
with Cabal version 1.2 and the `cabal-version` field is now required.
Files written in the old syntax are still recognized, so if you require
compatability with very old Cabal versions then you may write your package
compatibility with very old Cabal versions then you may write your package
description file using the old syntax. Please consult the user's guide of
an older Cabal version for a description of that syntax.
......@@ -837,7 +837,7 @@ describe the package as a whole:
`bug-reports:` _URL_
: The URL where users should direct bug reports. This would normally be either:
* A `mailto:` URL, eg for a person or a mailing list.
* A `mailto:` URL, e.g. for a person or a mailing list.
* An `http:` (or `https:`) URL for an online bug tracking system.
......@@ -1743,7 +1743,7 @@ are currently two kinds defined:
You can specify one kind or the other or both. As an example here are
the repositories for the Cabal library. Note that the `this` kind of
repo specifies a tag.
repository specifies a tag.
~~~~~~~~~~~~~~~~
source-repository head
......@@ -1787,8 +1787,8 @@ The exact fields are as follows:
: CVS requires a named module, as each CVS server can host multiple
named repositories.
This field is required for the CVS repo type and should not be used
otherwise.
This field is required for the CVS repository type and should not
be used otherwise.
`branch:` _token_
: Many source control systems support the notion of a branch, as a
......@@ -1801,17 +1801,17 @@ The exact fields are as follows:
`tag:` _token_
: A tag identifies a particular state of a source repository. The tag
can be used with a `this` repo kind to identify the state of a repo
corresponding to a particular package version or release. The exact
form of the tag depends on the repository type.
can be used with a `this` repository kind to identify the state of
a repository corresponding to a particular package version or
release. The exact form of the tag depends on the repository type.
This field is required for the `this` repo kind.
This field is required for the `this` repository kind.
`subdir:` _directory_
: Some projects put the sources for multiple packages under a single
source repository. This field lets you specify the relative path
from the root of the repository to the top directory for the
package, ie the directory containing the package's `.cabal` file.
package, i.e. the directory containing the package's `.cabal` file.
This field is optional. It default to empty which corresponds to the
root directory of the repository.
......@@ -1834,7 +1834,7 @@ The `get` command supports the following options:
`-s --source-repository` _[head|this|...]_
: Fork the package's source repository using the appropriate version control
system. The optional argument allows to choose a specific repo kind.
system. The optional argument allows to choose a specific repository kind.
## Accessing data files from package code ##
......
......@@ -163,7 +163,7 @@ Cabal is often compared with autoconf and automake and there is some
overlap in functionality. The most obvious similarity is that the
command line interface for actually configuring and building packages
follows the same steps and has many of the same configuration
paramaters.
parameters.
~~~~~~~~~~
./configure --prefix=...
......@@ -182,7 +182,7 @@ cabal install
Cabal's build system for simple packages is considerably less flexible
than make/automake, but has builtin knowledge of how to build Haskell
code and requires very little manual configuration. Cabal's simple build
system is also portable to Windows, without needing a unix-like
system is also portable to Windows, without needing a Unix-like
environment such as cygwin/mingwin.
Compared to autoconf, Cabal takes a somewhat different approach to
......
......@@ -216,7 +216,7 @@ $ cabal --ignore-sandbox install text
## Creating a binary package ##
When creating binary packages (e.g. for RedHat or Debian) one needs to
When creating binary packages (e.g. for Red Hat or Debian) one needs to
create a tarball that can be sent to another system for unpacking in the
root directory:
......@@ -316,7 +316,7 @@ files of a package:
: Specify additional options to the program _prog_. Any program known
to Cabal can be used in place of _prog_. For example:
`--alex-options="--template=mytemplatedir/"`. The _options_ is split
into program options based on spaces. Any options containing embeded
into program options based on spaces. Any options containing embedded
spaced need to be quoted, for example
`--foo-options='--bar="C:\Program File\Bar"'`. As an alternative
that takes only one option at a time but avoids the need to quote,
......@@ -324,8 +324,8 @@ files of a package:
`--`_`prog`_`-option=`_option_
: Specify a single additional option to the program _prog_. For
passing an option that contain embeded spaces, such as a file name
with embeded spaces, using this rather than `--`_`prog`_`-options`
passing an option that contain embedded spaces, such as a file name
with embedded spaces, using this rather than `--`_`prog`_`-options`
means you do not need an additional level of quoting. Of course if
you are using a command shell you may still need to quote, for
example `--foo-options="--bar=C:\Program File\Bar"`.
......@@ -445,7 +445,7 @@ independence](#prefix-independence)).
`$prefix`
: The path variable that stands for the root of the installation. For
an installation to be relocatable, all other instllation paths must
an installation to be relocatable, all other installation paths must
be relative to the `$prefix` variable.
`$bindir`
......@@ -468,23 +468,23 @@ independence](#prefix-independence)).
: As above but for `--docdir`
`$pkgid`
: The name and version of the package, eg `mypkg-0.2`
: The name and version of the package, e.g. `mypkg-0.2`
`$pkg`
: The name of the package, eg `mypkg`
: The name of the package, e.g. `mypkg`
`$version`
: The version of the package, eg `0.2`
: The version of the package, e.g. `0.2`
`$compiler`
: The compiler being used to build the package, eg `ghc-6.6.1`
: The compiler being used to build the package, e.g. `ghc-6.6.1`
`$os`
: The operating system of the computer being used to build the
package, eg `linux`, `windows`, `osx`, `freebsd` or `solaris`
package, e.g. `linux`, `windows`, `osx`, `freebsd` or `solaris`
`$arch`
: The architecture of the computer being used to build the package, eg
: The architecture of the computer being used to build the package, e.g.
`i386`, `x86_64`, `ppc` or `sparc`
#### Paths in the simple build system ####
......@@ -584,7 +584,7 @@ be controlled with the following command line options.
: (default) Does a global installation. In this case package
dependencies must be satisfied by the global package database. All
packages in the user's package database will be ignored. Typically
the final instllation step will require administrative privileges.
the final installation step will require administrative privileges.
`--package-db=`_db_
: Allows package dependencies to be satisfied from this additional
......@@ -675,7 +675,7 @@ be controlled with the following command line options.
example if you want to debug the C parts of a program containing
both Haskell and C code. Another reason is if your are building a
package for a system which has a policy of managing the stripping
itself (such as some linux distributions).
itself (such as some Linux distributions).
`--enable-shared`
: Build shared library. This implies a separate compiler run to
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment