Permalink
Commits on Oct 7, 2006
  1. Bump version to 1.1.5.9.4

    dcoutts committed Oct 7, 2006
  2. Only use -package-name with the package's version number for ghc-6.4

    dcoutts committed Oct 7, 2006
    This change was added for ghc-6.6 but broke packages for ghc-6.2.2.
  3. Have the default make target be build rather than test

    dcoutts committed Oct 7, 2006
    This is more normal.
Commits on Oct 5, 2006
  1. Read the buildinfo for the haddock step.

    dcoutts committed Oct 5, 2006
    In particular this means we pick up any cc-options that are
    needed for preprocessing the source before haddock reads it.
    This fixes the haddock build step for many of the packages in
    the ghc-extralibs collection.
Commits on Sep 26, 2006
Commits on Sep 22, 2006
Commits on Sep 11, 2006
  1. TAG 1.1.5.9.3

    dcoutts committed Sep 11, 2006
  2. Make Distribution.Compat.FilePath public and Distribution.Compat.Read…

    dcoutts committed Sep 11, 2006
    …P private
    
    Ideally all the Distribution.Compat.* modules would be private,
    however there is currently no sensible alternative to the FilePath module
    and hiding it at this stage breaks packages.
Commits on Sep 10, 2006
  1. cleanups to user's guide

    Ross Paterson
    Ross Paterson committed Sep 10, 2006
     * markup fixes
     * spelling
     * id's for some elements to avoid warnings
     * mention the use of Description field by setup haddock
     * clean up --hoogle description
Commits on Sep 8, 2006
  1. Check exit codes!

    dcoutts committed Sep 8, 2006
    Cabal was not noticing haddock failing. That's bad.
Commits on Sep 6, 2006
  1. Use a versioned tarball

    dcoutts committed Sep 6, 2006
  2. Remove all the old cabal-install dependencies

    dcoutts committed Sep 6, 2006
    The newer cabal-install has different and fewer deps.
    We will add those in for a release including cabal-install.
  3. Don't build with -Wall for the release.

    dcoutts committed Sep 6, 2006
    It just makes us look bad! :-)
  4. Fix testsuite to use compiler version-specific paths properly

    dcoutts committed Sep 6, 2006
    It was using constant strings like "lib/ghc-6.4.1/blah"
    which obviously doesn't work very well with ghc-6.5.20060903
    Also let the test to run be specified on the command line to
    make it easier to re-run individual tests.
  5. Remove extensions and options that are only needed for cabal-install

    dcoutts committed Sep 6, 2006
    Since we're not shipping cabal-install or cabal-setup just yet.
Commits on Sep 5, 2006
Commits on Sep 2, 2006
  1. We don't really depend on mtl or network

    dcoutts committed Sep 2, 2006
    No idea why they were there, it builds fine without.
    Having these deps causes circular dependencies for package-based
    distros like Gentoo since mtl and network are not in the core set
    of libs and they both need cabal to build.
Commits on Sep 1, 2006
Commits on Aug 27, 2006
Commits on Aug 23, 2006
  1. Use slightly simpler way of getting GHC version.

    dcoutts committed Aug 23, 2006
    ghc has supported --numeric-version for ages.
  2. Be cleverer about guessing hc-pkg name and location.

    dcoutts committed Aug 23, 2006
    So it now works if you say:
    ./setup configure --with-compiler=ghc-6.5
    ie specifying a path-relative name rather than an absolute path.
    We then look for hc-pkg in the same dir as where we found the compiler.
    If the compiler appears to have a version suffix then we additionally
    and preferentially look for hc-pkg with that same version suffix.
    (I'm not sure that bit works if you've got a .exe suffix, perhaps a
    windows person could try it / take a look)