Cabal-1.10.2.0: A framework for packaging Haskell software

Portability | portable
Maintainer | cabal-devel@haskell.org

Distribution.Make

Description

This is an alternative build system that delegates everything to the `make` program. All the commands just end up calling `make` with appropriate arguments. The intention was to allow preexisting packages that used makefiles to be wrapped into Cabal packages. In practice essentially all such packages were converted over to the "Simple" build system instead. Consequently this module is not used much and it certainly only sees cursory maintenance and no testing. Perhaps at some point we should stop pretending that it works.

Uses the parsed command-line from Distribution.Simple.Setup in order to build Haskell tools using a backend build system based on make. Obviously we assume that there is a configure script, and that after the ConfigCmd has been run, there is a Makefile. Further assumptions:

ConfigCmd
  We assume the configure script accepts `--with-hc`, `--with-hc-pkg`, `--prefix`, `--bindir`, `--libdir`, `--libexecdir`, `--datadir`.
BuildCmd
  We assume that the default Makefile target will build everything.
InstallCmd
  We assume there is an `install` target. Note that we assume that this does *not* register the package!
CopyCmd
  We assume there is a `copy` target, and a variable `$(destdir)`. The `copy` target should probably just invoke `make install` recursively (e.g. `$(MAKE) install prefix=$(destdir)/$(prefix) bindir=$(destdir)/$(bindir)`. The reason we can't invoke `make install` directly here is that we don't know the value of `$(prefix)`.
SDistCmd
  We assume there is a `dist` target.
RegisterCmd
  We assume there is a `register` target and a variable `$(user)`.
UnregisterCmd
  We assume there is an `unregister` target.
HaddockCmd
  We assume there is a `docs` or `doc` target.

Synopsis

- module Distribution.Package
- data License
  - = GPL (Maybe Version)
  - | LGPL (Maybe Version)
  - | BSD3
  - | BSD4
  - | MIT
  - | PublicDomain
  - | AllRightsReserved
  - | OtherLicense
  - | UnknownLicense String
- data Version = Version {
  - versionBranch :: [Int]
  - versionTags :: [String]
  }
- defaultMain :: IO ()
- defaultMainArgs :: [String] -> IO ()
- defaultMainNoRead :: PackageDescription -> IO ()

# Documentation

module Distribution.Package

data License Source

This datatype indicates the license under which your package is released. It is also wise to add your license to each source file using the license-file field. The `AllRightsReserved` constructor is not actually a license, but states that you are not giving anyone else a license to use or distribute your work. The comments below are general guidelines. Please read the licenses themselves and consult a lawyer if you are unsure of your rights to release the software.

Constructors

GPL (Maybe Version) | GNU Public License. Source code must accompany alterations.
LGPL (Maybe Version) | Lesser GPL, Less restrictive than GPL, useful for libraries.
BSD3 | 3-clause BSD license, newer, no advertising clause. Very free license.
BSD4 | 4-clause BSD license, older, with advertising clause. You almost certainly want to use the BSD3 license instead.
MIT | The MIT license, similar to the BSD3. Very free license.
PublicDomain | Holder makes no claim to ownership, least restrictive license.
AllRightsReserved | No rights are granted to others. Undistributable. Most restrictive.
OtherLicense | Some other license.
UnknownLicense String | Not a recognised license. Allows us to deal with future extensions more gracefully.

Instances

Eq License |
Read License |
Show License |
Text License |

data Version Source

A `Version` represents the version of a software entity.

An instance of `Eq` is provided, which implements exact equality modulo reordering of the tags in the `versionTags` field.

An instance of `Ord` is also provided, which gives lexicographic ordering on the `versionBranch` fields (i.e. 2.1 > 2.0, 1.2.3 > 1.2.2, etc.). This is expected to be sufficient for many uses, but note that you may need to use a more specific ordering for your versioning scheme. For example, some versioning schemes may include pre-releases which have tags `"pre1"`, `"pre2"`, and so on, and these would need to be taken into account when determining ordering. In some cases, date ordering may be more appropriate, so the application would have to look for `date` tags in the `versionTags` field and compare those. The bottom line is, don't always assume that `compare` and other `Ord` operations are the right thing for every `Version`.

Similarly, concrete representations of versions may differ. One possible concrete representation is provided (see `showVersion` and `parseVersion`), but depending on the application a different concrete representation may be more appropriate.

Constructors

Version |

Fields

versionBranch :: [Int]

  The numeric branch for this version. This reflects the fact that most software versions are tree-structured; there is a main trunk which is tagged with versions at various points (1,2,3...), and the first branch off the trunk after version 3 is 3.1, the second branch off the trunk after version 3 is 3.2, and so on. The tree can be branched arbitrarily, just by adding more digits.

  We represent the branch as a list of `Int`, so version 3.2.1 becomes [3,2,1]. Lexicographic ordering (i.e. the default instance of `Ord` for `[Int]`) gives the natural ordering of branches.

versionTags :: [String]

  A version can be tagged with an arbitrary list of strings. The interpretation of the list of tags is entirely dependent on the entity that this version applies to.

Instances

Eq Version |
Ord Version |
Read Version |
Show Version |
Typeable Version |
Text Version |

defaultMain :: IO ()Source

defaultMainArgs :: [String] -> IO ()Source

defaultMainNoRead :: PackageDescription -> IO ()Source