Here's a status update. ## Faster builds
We've made good progress on making things faster. In particular, we've implemented: * Re-linking avoidance (https://github.com/haskell/cabal/pull/1537). This is really useful if you have e.g. many test suites and only one needs to be rebuilt due to some change to the library. * Parallel builds at the module level ( https://github.com/haskell/cabal/pull/1536). This gives a modest speed-up for `cabal build`, especially for larger packages. ## Do the right thing automatically No progress here. Both tasks should be pretty straightforward. Anyone interested in taking a stab at them? I'd be happy to provide guidance. ## Support large projects We haven't yet made any progress on support for trees of packages. We're in need of a design doc here before we can do much else. There is some important work on freezing dependencies for releases under way at https://github.com/haskell/cabal/pull/1519. That thread could probably need some input for people other than me. -- Johan On Thu, Sep 5, 2013 at 6:14 AM, Johan Tibell <johan.tib...@gmail.com> wrote: > Hi all, > > With 1.18 out the door it's time to look towards the future. Here are > the major themes I'd like to see us work on next: > > ## Faster builds > > There are several interesting things we could do and are doing here. > > * Avoid relinking if possible. This reduces incremental build times > (i.e. when you run cabal build after making some change) by avoiding > relinking e.g. all the test suites and/or benchmarks. See > https://github.com/haskell/cabal/pull/1410 for some in-progress work. > > * Build components and different ways (e.g. profiling) in parallel. > We could build both profiling and non-profiling versions in parallel. > We could also build e.g. all test suites in parallel. The key > challenge here is to coordinate all parallel jobs so we don't spawn > too many. See https://github.com/haskell/cabal/pull/1413 > > * Build modules in parallel. This fine granularity would let us > making building a single package faster, which is the most common case > after all. There has been some GSoC work here e.g. > http://hackage.haskell.org/trac/ghc/ticket/910 and some work by > Mikhail. > > ## Do the right thing automatically > > The focus here should be on avoiding manual steps the cabal could do > for the user. > > * Automatically install dependencies when needed. When `cabal build` > would fail due to a missing dependency, just install this dependency > instead of bugging the user to do it. This will probably have to be > limited to sandboxes where we can't break the user's system > > * GHCi support could be improved by rebinding :reload to rerun e.g. > preprocessors automatically. This would enable the users to develop > completely from within ghci (i.e. faster edit-save-type-error cycle). > We have most of what we need here (i.e. GHC macro support) but someone > needs to make the final change to generate a .ghci file to pass in the > ghci invocation. > > ## Support large projects > > We need to better support projects with tens or hundreds of packages. > As projects grow it's naturally to split them up into a bunch of > packages (libraries and executables). Some changes to the project > might need changes across a couple of packages (e.g. to a supporting > library and to an executable) in a single change and developers need > to be able to > > * build several packages that have local changes, and > * share changes to packages with other developers without making a > release to some local Hackage server every time. > > Both can be done by having a single source repo with all the packages > and using `cabal sandbox add-source` to make sure they get built when > needed. However, that method only scales up to a handful of packages. > > I think we want to think about moving away from a world where all > cabal commands are run in the context of some "current" package (i.e. > in the current working directory). I think we want to be able to stand > in the root directory of some source repo and build things from there. > Example: > > $ git clone git://my-company/repo my-project > $ cd my-project > $ ls > lib-pkg1 lib-pkg2 exe-pkg1 exe-pkg2 ... > $ cabal sandbox init # or something similar > $ edit lib-pkg1/Lib.hs > $ edit exe-pkg1/Exe.hs > $ cabal build exe-pkg1 # picks up changes to lib-pkg1 > > This has implication for many things e.g. where the .cabal-sandbo and > the dist directories are kept. Perhaps dist would have a subdirectory > per package (right now we do something similar for sandbox > dependencies). > > I imagine that the syntax for e.g. cabal build would have to extended to > > cabal build [[DIR':']COMPONENT] > > Example: > > cabal build lib-pkg1:some-component > > Similar for `cabal test` and `cabal bench`. > > Cheers, > Johan >
_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
