Commit 5a890bfc authored by Jan Hrček's avatar Jan Hrček Committed by Oleg Grenrus

Fixes in Package description chapter

parent ff9555f8
......@@ -1361,7 +1361,7 @@ checkCabalVersion pkg =
-- * Checks on the GenericPackageDescription
-- ------------------------------------------------------------
-- | Check the build-depends fields for any weirdness or bad practise.
-- | Check the build-depends fields for any weirdness or bad practice.
--
checkPackageVersions :: GenericPackageDescription -> [PackageCheck]
checkPackageVersions pkg =
......@@ -1376,7 +1376,7 @@ checkPackageVersions pkg =
"The dependency 'build-depends: base' does not specify an upper "
++ "bound on the version number. Each major release of the 'base' "
++ "package changes the API in various ways and most packages will "
++ "need some changes to compile with it. The recommended practise "
++ "need some changes to compile with it. The recommended practice "
++ "is to specify an upper bound on the version of the 'base' "
++ "package. This ensures your package will continue to build when a "
++ "new major version of the 'base' package is released. If you are "
......
......@@ -1536,7 +1536,7 @@ system-dependent values for these fields.
In order to specify an intra-package dependency on an internal
library component you can use the unqualified name of the
component library component. Note that locally defined sub-library
library component. Note that locally defined sub-library
names shadow external package names of the same name. See section on
:ref:`Internal Libraries <sublibs>` for examples and more information.
......@@ -1556,7 +1556,7 @@ system-dependent values for these fields.
bar
Dependencies like ``foo >= 1.2.3 && < 1.3`` turn out to be very
common because it is recommended practise for package versions to
common because it is recommended practice for package versions to
correspond to API versions (see PVP_).
Since Cabal 1.6, there is a special wildcard syntax to help with
......@@ -1637,7 +1637,7 @@ system-dependent values for these fields.
.. Note::
One might expected the desugaring to truncate all version
One might expect the desugaring to truncate all version
components below (and including) the patch-level, i.e.
``^>= x.y.z.u`` == ``>= x.y.z && < x.(y+1)``,
as the major and minor version components alone are supposed to
......@@ -2262,7 +2262,7 @@ Example: A package containing a library and executable programs
Flag NewDirectory
description: Whether to build against @directory >= 1.2@
-- This is an automatic flag which the solver will be
-- This is an automatic flag which the solver will
-- assign automatically while searching for a solution
Library
......@@ -2530,8 +2530,8 @@ Meaning of field values when using conditionals
During the configuration phase, a flag assignment is chosen, all
conditionals are evaluated, and the package description is combined into
a flat package descriptions. If the same field both inside a conditional
and outside then they are combined using the following rules.
a flat package descriptions. If the same field is declared both inside
a conditional and outside then they are combined using the following rules.
- Boolean fields are combined using conjunction (logical "and").
......@@ -2621,7 +2621,7 @@ Source Repositories
:since: 1.6
It is often useful to be able to specify a source revision control
repository for a package. Cabal lets you specifying this information in
repository for a package. Cabal lets you specify this information in
a relatively structured form which enables other tools to interpret and
make effective use of the information. For example the information
should be sufficient for an automatic tool to checkout the sources.
......@@ -2704,7 +2704,7 @@ The exact fields are as follows:
Many source control systems support the notion of a branch, as a
distinct concept from having repositories in separate locations. For
example CVS, SVN and git use branches while for darcs uses different
example CVS, SVN and git use branches while darcs uses different
locations for different branches. If you need to specify a branch to
identify a your repository then specify it in this field.
......@@ -2727,7 +2727,7 @@ The exact fields are as follows:
package, i.e. the directory containing the package's ``.cabal``
file.
This field is optional. It default to empty which corresponds to the
This field is optional. It defaults to empty which corresponds to the
root directory of the repository.
Downloading a package's source
......@@ -2765,7 +2765,7 @@ Custom setup scripts
Since Cabal 1.24, custom ``Setup.hs`` are required to accurately track
their dependencies by declaring them in the ``.cabal`` file rather than
rely on dependencies being implicitly in scope. Please refer
rely on dependencies being implicitly in scope. Please refer to
`this article <https://www.well-typed.com/blog/2015/07/cabal-setup-deps/>`__
for more details.
......@@ -2889,7 +2889,7 @@ really on the package when distributed. This makes commands like sdist fail
because the file is not found.
These special modules must appear again on the :pkg-field:`autogen-modules`
field of the stanza that is using it, besides :pkg-field:`other-modules` or
field of the stanza that is using them, besides :pkg-field:`other-modules` or
:pkg-field:`library:exposed-modules`. With this there is no need to create
complex build hooks for this poweruser case.
......
......@@ -60,7 +60,7 @@ will be no incompatible API changes. But minor versions increments, for
example 1.2.3, indicate compatible API additions.
The Package Versioning Policy does not require any API guarantees
between major releases, for example between 1.2.x and 1.4.x. In practise
between major releases, for example between 1.2.x and 1.4.x. In practice
of course not everything changes between major releases. Some parts of
the API are more prone to change than others. The rest of this section
gives some informal advice on what level of API stability you can expect
......
......@@ -119,7 +119,7 @@ across projects. To be more precise:
``packages``, ``optional-packages`` or ``extra-packages`` field of a
project. Usually, these refer to packages whose source code lives
directly in a folder in your project. But you can list an
arbitrary Hackage package in `extra-packages <cabal-project.html#cfg-field-extra-packages>`
arbitrary Hackage package in :cfg-field:`packages`
to force it to be treated as local.
Local packages, as well as the external packages (below) which depend on
......@@ -261,4 +261,4 @@ this folder (the most important two are first):
Note that every package also has a local cache managed by the Cabal
build system, e.g., in ``$distdir/cache``.
\ No newline at end of file
build system, e.g., in ``$distdir/cache``.
......@@ -3,4 +3,4 @@ No 'category' field.
No 'maintainer' field.
No 'description' field.
The 'license' field is missing or is NONE.
The dependency 'build-depends: base' does not specify an upper bound on the version number. Each major release of the 'base' package changes the API in various ways and most packages will need some changes to compile with it. The recommended practise is to specify an upper bound on the version of the 'base' package. This ensures your package will continue to build when a new major version of the 'base' package is released. If you are not sure what upper bound to use then use the next major version. For example if you have tested your package with 'base' version 4.5 and 4.6 then use 'build-depends: base >= 4.5 && < 4.7'.
The dependency 'build-depends: base' does not specify an upper bound on the version number. Each major release of the 'base' package changes the API in various ways and most packages will need some changes to compile with it. The recommended practice is to specify an upper bound on the version of the 'base' package. This ensures your package will continue to build when a new major version of the 'base' package is released. If you are not sure what upper bound to use then use the next major version. For example if you have tested your package with 'base' version 4.5 and 4.6 then use 'build-depends: base >= 4.5 && < 4.7'.
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