Splitting a big Cabal package into small ones

[Isaac Jones]

Henning Thielemann <lemming at henning-thielemann.de> writes:

>  I'm still thinking about how to manage splitting a big Cabal package into
> an easily portable core package and sub-packages for special features,
> while still presenting everything as a single project.
>
>  People have proposed using the CPP preprocessor, but I want to keep this
> out of my Haskell modules. The radical way is splitting a big Cabal
> package into smaller ones. But then the Haddock documentation is also
> split (namely the contents and index file), 

Isn't there a way for the haddock documents to be generated together
using certain haddock flags?  Wouldn't it be nicer to just add this
feature to cabal somehow?  Are there any existing proposals that solve
this question?

> the sub-packages must be downloaded and compiled separately, in the
> right order (I know that cabal-get will simplify that).

It'll be cabal-install, and if you want to help hack on that, you're
more than welcome :)

> Further on the project will be shipped by Cabal in separate
> archives, and I guess I have to duplicate the directory structure
> for my project (module A.B.C goes to sub-package X and module A.B.D
> goes to sub-package Y) and I have complicated recompilations after
> changes in the core package. Even more I always have to install the
> recompiled core before I can access it from a sub-package.

Sholdn't module A and B go into package Z, and C (from package X)
depend on Z, etc?

>  I tried to solve the problem by composing a user dependent Cabal file
> from small Cabal files in the configure phase. That is I divide the big
> Cabal file into small ones for each sub-package. 

This approach will probably break cabal-install.  Generating .cabal
files is not really approved :)

> Then 'Setup.lhs
> configure' is implemented that way, that it finds out the dependencies of
> the sub-packages and configures them in the right order. If one
> configuration fails, the sub-package and all its dependents are excluded.  
> I merge the successfully configured sub-packages into a big Cabal file.
>  This method let me still handle the project as one unit, the Haddock
> documentation is merged and no intermediate installations of packages are
> necessary on recompilation. However this technique is not optimal because
> foreign packages may depend on special features provided by sub-packages
> which are not installed on a particular machine.

I'm curious, why do folks frequently implement complex external tools
like this for features that probably belong in Cabal, rather than
contributing to cabal itself?  I'm not criticizing, I'm just wondering
what we develpers can do to make Cabal hacking more approachable.

peace,

  isaac