Splitting a big Cabal package into small ones

[Henning Thielemann]

On Thu, 24 Aug 2006, Isaac Jones wrote:

> 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?

Somehow haddock can do this. We would need some agreement where to install
a global index file. This would depend on whether the current package is
global or local. I could even add that feature by myself, since I already
successfully improved the Haddock support. :-)

> > 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?

Is this a question concerning the splitting of the package without
splitting the development location?

> >  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 :)

I suspected this. :-(

> > 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.

The reason is simply that I have to experiment with it before adding it to
Cabal. It wouldn't be sensible to add ill-designed, non-working, or even
non-compiling code to the Cabal package. Even more development in a local
Setup file is simpler than compiling and installing Cabal after each
change. As it looks now, my experiments are not successful and I will not
bother anyone with my code.  Unless someone asks for it.