GitLab

There's a new field for .cabal files: 

     install-includes: foo.h bar.h

This means the same as 'includes', except that the files named therein
will be installed into $libdir/include.  'includes' should only be
used for headers already installed on the system.

Directories listed in 'include-dirs' still turn into -I options for
hsc2hs, cpphs, and C compilations.  However, for installation
purposes, relative directories in 'include-dirs' are now treated
differently from absolute directories:

  - an absolute directory is copied to the include-dirs field
    of the installed package config

  - files names in install-includes are assumed to be found in
    one of the *relative* directories listed in include-dirs

So the common pattern for providing a header file that you want to
be available everywhere including to via-C compilations against this
package:

  include-dirs: myincludes
  install-includes: foo.h

will install the header file myincludes/foo.h in
$libdir/include/foo.h.

Wed Apr 26 13:11:10 BST 2006  Simon Marlow <simonmar@microsoft.com>
  * RequireOrder: do not collect unrecognised options after a non-opt

Previously, options before the command name other than --help were
just ignored, which is quite confusing behaviour.  So now,

./setup --with-compiler=ghc-6.4.2 configure

works as you expect, instead of ignoring the --with-compiler option.

cabal-setup is a replacement for 'runhaskell Setup.hs'.  It accepts
exactly the same commands.  Additionally, the following new features
are provided:

 * Setup.{hs,lhs} is optional.  If omitted, cabal-setup behaves just
   like Distribution.Simple.defaultMain.

 * If the .cabal file contains a cabal-version field, then Setup.hs
   is built using an appropriate version of Cabal.  This might entail
   creating Setup.hs if it doesn't exist.

 * cabal-setup interprets the options --with-compiler and --with-hc-pkg
   to determine the compiler used to compile Setup.hs.

Later, we could add support for building multiple packages in
dependency order, as per recent discussions on libraries@haskell.org.

 
There are a few changes in this patch:
 
   - New flag to register, --inplace.  "setup register --inplace"
     registers the package for use in the build tree, i.e. without
     installing.  It works with GHC only, currently.
     
   - The parameters to RegisterCmd, UnregisterCmd and InstallCmd are a
     legacy from before the time of hooks (or something) and don't
     serve any purpose any more, AFAICT.  So I removed them.
 
   - I don't think "setup register" worked propertly before if
     --user was given to configure.  It does now.

   - New flag to register: --with-hc-pkg (just the same as when
     given to configure, but lets you override it at register-time)

This also matches package.conf.in.

This also matches Cabal.cabal.

For ghc-6.4 when Cabal registers packages it exposes them by default.
However it does not do the same fo ghc-6.2. This change corrects the
discrepancy. This patch is already being used in Gentoo with Cabal 1.1.3.

It is no longer necessary to run 'configure' before 'clean' or 'sdist', addressing http://haskell.galois.com/trac/hackage/ticket/12.
In order to change this behaviour, it was necessary to modify the hook interface, specifically cleanHook, postClean, sDistHook, postSDist.  They now take a Maybe LocalBuildInfo, since a LocalBuildInfo might not be available in .setup-config.

because parsers are evaluated multiple times due to backtracking.

New configure option: --enable-split-objs creates libraries using
-split-objs with GHC (current HEAD or later only, the configure checks
for version 6.5).  Fixes ticket #19.

just ignore the extra ParseOk warnings field

Add support for warnings to the ParseResult type. Change existing
warnings from using Debug.Trace to use this new warning support.

Summary if last few changes: I modified the hooks interface quite a
bit, again.  There's good news and bad news about this.  The good news
is that it's cleaned up and should be easier to maintain and to avoid
future modifications.  The bad news is that this change itself will
break stuff, of course.

If you have any trouble building your Setup scripts, please let me
know.  I really think that it was best to bite the bullet right now in
one big go instead of down the road with lots of little changes.  I
have a lot more confidence in the hooks interface, and I don't
actually expect that it'll change as often.

I made the types more consistent, and made sure there are accessor
functions on each of the Flags types so that if the flags types change
in the future, it shouldn't break lots of code.

Another piece of good / bad news is that I decided not to get rid of
the pre & post hooks.  They are nice for convenience and it wouldn't
be nearly so easy to write hooks without them.

That's bad because the interface to hooks is still pretty big, which
means that there's more likelihood that it'll change in the future.

Another weakness in the Hooks interface is that with command hooks
(like sDistHook) it's tempting to add parameters to them; basically
the stuff that we compute between the preSDist and sDist hook.  I
removed such params and have their values computed elsewhere.

Cabal hackers, please avoid adding parameters to these command hooks
if at all possible in order to keep the interface steady.  If you need
to compute a value to pass to these functions, compute it in the
function and / or make it available as a function that someone
crafting hooks can use as well, or consider whether it belongs in one
of the parameters already being passed to the hooks,
PackageDescription, LocalBuildInfo, UserHooks, Flags.