Splitting a big Cabal package into small ones
lemming at henning-thielemann.de
Mon Aug 28 05:45:37 EDT 2006
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.
More information about the cabal-devel