johan.tibell at gmail.com
Mon Nov 11 09:46:22 UTC 2013
Here's a status update.
## Faster builds
We've made good progress on making things faster. In particular, we've
* 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.
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
> ## 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.
> $ 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
> I imagine that the syntax for e.g. cabal build would have to extended to
> cabal build [[DIR':']COMPONENT]
> cabal build lib-pkg1:some-component
> Similar for `cabal test` and `cabal bench`.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cabal-devel