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:

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).

Documentation

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.

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.

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.