 | Cabal-1.8.0.4: A framework for packaging Haskell software | Contents | Index |
|
| Distribution.Make | | Portability | portable | | Maintainer | cabal-devel@haskell.org |
|
|
|
| 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.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 |
|
|
|
| Documentation |
|
| module Distribution.Package |
|
| data License |
| 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 | |
|
|
| data Version |
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 | | | 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 | |
|
|
| defaultMain :: IO () |
|
| defaultMainArgs :: [String] -> IO () |
|
| defaultMainNoRead :: PackageDescription -> IO () |
|
| Produced by Haddock version 2.6.0 |