[GSoC] Cabal 'make-like' dependency framework

[Max Desyatov]

Hi,

There are only few hours until the deadline, but I still have some hope
 to receive comments to improve my proposal.

The goal of the project I am intending to do is to develop a working
prototype of a make-style module/file dependency framework for the
Cabal, which is the most actively evolving Haskell build system at the
moment.

At this time building process with Cabal is somewhat imperative and
depends on GHC's "--make" option or hmake when building modules
written in the Haskell language.  Thus, new dependency system should
support its own module chasing from a description given the
declarative style, which would give a possibility to add many new
features and resolve old bugs in the Haskell Cabal (as there are
currently more than 10 tickets which depend on the dependency tracking
implementation).  Pre-processors (c2hs e.g.) and some other Haskell
compilers, which don't have their own dependency system, would greatly
benefit from this improvement.  Gtk2hs will also greatly benefit from
this project, as at this time it uses shell language and limited
functional language on top (make) for its build system which prevents
handling of dynamic dependencies in the right way.  Absence of
dependencies tracking in Cabal prevents gtkhs to be cabalised fully.

Getting some ideas from the first sketchy prototype we can see that
dynamic dependencies should be supported, i.e. some actions can be run
while computing the dependency graph.

The plan to deploy the code of the project in the real use cases is to
code dependency resolver for yhc or nhc98 (depends on the difficulty
of integration with existing compiler codebase).  Doing this won't
hurt ghc support, which is quite important.

The great part of the work is contriving an embedded domain specific
language for the make actions specification.  This will reduce
complexity, role of imperative parts and code size of Cabal in
general.  The form of this EDSL needs careful investigation.

The system should be fairly generic and extensible for actions and
rules to be expressed crearly.  Framework can be customised with
pre-processors or other actions which are run in the process of the
dependency resolving.

For the aid in testing and clarifying project goals some sophisticated
examples will be constructed (using pre-processors, cases with search
path shadowing etc).  Seeing the existing problems we can decide how
to improve Cabal for their resolution.  With the
help of parametrisation over a type of used monad for actions we can
do tests without any IO through QuickCheck.

Do you think there are some things in this abstract I should remove or I
should definitely add?  Are there some wrong assumptions or things that
can go beyond my project?

Thanks for advance for any advice, comment or question.

--
Max