What's next?

[Johan Tibell]

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.tibell at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20131111/b7d74be8/attachment-0001.html>