Henning Thielemann
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