What's next?

[Johan Tibell]

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