Extending Cabal

[John Meacham]

On Fri, May 13, 2005 at 09:23:18AM +0200, Henning Thielemann wrote:
> 
> On Thu, 12 May 2005, John Meacham wrote:
> 
> > On Thu, May 12, 2005 at 05:34:06PM +0100, Henrik Nilsson wrote:
> > > Hi all,
> > >
> > > Simon Marlow wrote:
> > >
> > > > It's a trivial change to make, it doesn't break anything, and it lets
> > > > us support more existing projects without substantial reorganisation
> > > > of their file structure.  Sounds like a no-brainer to me.
> > >
> > > I've never liked the close de-facto connection between the hierarchical
> > > module name space and and the actual source tree.
> 
> I don't see the advantage of giving every programmer his own style in this
> respect, or even allow mixing dotted file names and separation by
> directories. When I read
>  import Control.Monad.Writer
>   I know that the file Writer.hs is in Control/Monad, very easy. What's so
> bad about using directories? Bad support by CVS? Then use darcs.
> Separating module names and file locations adds a new level of complexity
> but for what benefit?

It is funny you should mention this. I need this feature exactly to get
around limitations of darcs that wern't a problem with CVS :).
Darcs can't compose multiple repositories such that they share a root,
therefore in order to compose several haskell projects, I need to treat
each of their source directories as potential locations of haskell code. 

There are a _lot_ of external factors that constrain the way one may lay
out files. Making cabal less flexible in this regard would only make it
less likely to be adopted. I already had to jump through hoops to get
hierarchical names to play well with automake due to its ideas of what
goes in subdirectories were different than haskells and it wasn't very
fun and not the sort of thing I like to do. (fight my tools)  We should
make cabal very flexible if we expect it to be used.

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈