Skip to content

Latest commit

 

History

History
104 lines (78 loc) · 4.17 KB

0.8.md

File metadata and controls

104 lines (78 loc) · 4.17 KB
Raw

cabal-dev release 0.8

The 0.8 release of cabal-dev fixes many of the bugs that have been reported by cabal-dev users. It also provides more flexible, easier configuration and improves tool support for working within the cabal-dev sandbox (ghc-pkg suport and better ghci support). Upgrading is recommended for all users.

Please report any bugs or submit enhancement requests to https://github.com/creswick/cabal-dev/issues.

Much of the work on this release (and previous releases) of cabal-dev was funded by Galois, Inc. http://www.galois.com/

About cabal-dev

cabal-dev is a Haskell build tool that augments Cabal and cabal-install to make it convenient to work with a sandboxed set of packages. It limits the effect of your build on unrelated parts of your system. Among other things, cabal-dev satisfies the following needs:

  • Avoid conflicts between libraries by working only with the set of packages that are needed for the current project.

  • Enable depending on a patched dependency without that patched dependency accidentally being used by another project's build.

  • Enable the simultaneous development of multiple interdependent packages without the development versions leaking to other project build environments.

Significant effort has been made to ensure that cabal-dev works across platforms (Mac, Windows, and Linux) and with the versions of GHC that are most commonly in use (6.10-7.0).

What's new

Details can be found on github at https://github.com/creswick/cabal-dev.

Bugs fixed:

  • cabal-dev no longer passes --verbose to cabal-install commands that do not accept it. #18

  • cabal-dev now recognizes and passes through short flags to cabal-install. In particular, this bug frequently came up when attempting to pass a flag (-f) to cabal-dev install. #6

  • cabal-dev now supports all cabal-install commands, including test. #10

  • We also made changes that should address inconsistencies with the remote repository (Hackage) cache location, but those issues remain open until we have confirmation from end users (you!) that these changes actually fix those issues. #15 and #14

Enhancements and new features:

  • cabal-dev ghci now invokes ghci with the exact same set of flags that would be used in a cabal-install build (using a trick copied from Leksah). This means that it will now have the appropriate package visibility, language settings, and source directories set when it is invoked.

    Note that in order for cabal-dev ghci to work, all dependencies must already be installed in the sandbox, and the package must already be configured.

  • cabal-dev buildopts will print the set of build options that would be passed to GHC when invoking cabal build. You can then use these flags for other tools that invoke GHC (e.g. the doctest package http://hackage.haskell.org/package/doctest).

  • cabal-dev ghc-pkg will invoke ghc-pkg with the appropriate flags to examine or alter the package database inside the cabal-dev sandbox.

  • cabal-dev now has more flexible support for cabal-install configuration:

    • By default cabal-dev will now use any settings from your cabal-install configuration file, except those that must be overridden in order to sandbox the build. This makes it more convenient to e.g. use an alternate remote repository with cabal-dev.

    • cabal-dev now supports merging of additional cabal-install configuration settings, to make it easy to work with multiple cabal-install configurations (--extra-config-file=...).

  • cabal-dev now has a flag to pass explicit options to cabal-install in case there are any conflicts between cabal-dev flags (--cabal-install-arg).

  • cabal-dev now has a flag to specify a particular cabal-install executable to use (--with-cabal-install=...).