
We're happy to announce the release of cabal-dev 0.8! This version is available on hackage now, and contains many bug fixes and improvements, as outlined in the full release notes below. --Rogan 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. https://github.com/creswick/cabal-dev/issues/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`. https://github.com/creswick/cabal-dev/issues/6 * `cabal-dev` now supports all cabal-install commands, including `test`. https://github.com/creswick/cabal-dev/issues/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. https://github.com/creswick/cabal-dev/issues/15 and https://github.com/creswick/cabal-dev/issues/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=...`).

On Mon, Jul 18, 2011 at 1:10 PM, Rogan Creswick
We're happy to announce the release of cabal-dev 0.8! This version is available on hackage now, and contains many bug fixes and improvements, as outlined in the full release notes below.
Wonderful! This is absolutely one of those indispensable tools for build automation and sanity preservation. I use cabal-dev to manage the builds for all of my Haskell projects, under many different configurations: https://jenkins.serpentine.com/

On Mon, 2011-07-18 at 15:29 -0700, Bryan O'Sullivan wrote:
Wonderful! This is absolutely one of those indispensable tools for build automation and sanity preservation. I use cabal-dev to manage the builds for all of my Haskell projects, under many different configurations: https://jenkins.serpentine.com/
Looks very interesting... do you happen to have described your Jenkins setup for Haskell development somewhere? -- hvr

On Tue, Jul 19, 2011 at 10:10 AM, Herbert Valerio Riedel
On Mon, 2011-07-18 at 15:29 -0700, Bryan O'Sullivan wrote:
Wonderful! This is absolutely one of those indispensable tools for build automation and sanity preservation. I use cabal-dev to manage the builds for all of my Haskell projects, under many different configurations: https://jenkins.serpentine.com/
Looks very interesting... do you happen to have described your Jenkins setup for Haskell development somewhere?
We use it too:
http://buildbot.snapframework.com/
It's extremely easy to set up, you just get Jenkins to issue all of
the shell commands you need to issue to build the project. For an
example, see the console output from our last snap-server build:
http://buildbot.snapframework.com/job/snap-server/build_mode=Default/lastBui...
Particular tips from our configuration:
* Jenkins is a Java project, and hence gobbles RAM. My VPS couldn't
handle it, so I run it over a VPN tunnel to a machine sitting in my
living room.
* If you set up test-framework to run your tests, you can get it to
spit out junit XML which Jenkins understands
* Get Jenkins to wrap up your haddocks and HPC test coverage
reports, it's really useful.
G
--
Gregory Collins

On Tue, 2011-07-19 at 10:33 +0200, Gregory Collins wrote:
Particular tips from our configuration:
* Jenkins is a Java project, and hence gobbles RAM. My VPS couldn't handle it, so I run it over a VPN tunnel to a machine sitting in my living room.
* If you set up test-framework to run your tests, you can get it to spit out junit XML which Jenkins understands
* Get Jenkins to wrap up your haddocks and HPC test coverage reports, it's really useful.
Yeah, that's what I got so far as well (based on what I could deduce from snapframework's Jenkins site some time ago) :-) What I'm particularly interested in now is how that "Compiler Warnings" works, see https://jenkins.serpentine.com/job/attoparsec/1/warningsResult/ or what's needed to get that compile-flags configuration matrix set up... and I was wondering, if someone has managed to graph a few more metrics (such as hpc's or haddock's coverage) as trend over builds via the plot-plugin or something similiar... -- hvr
participants (4)
-
Bryan O'Sullivan
-
Gregory Collins
-
Herbert Valerio Riedel
-
Rogan Creswick