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.