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. _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
