On 12/01/11 17:54, Kathleen Fisher wrote:
On Jan 12, 2011, at 3:59 AM, Henning Thielemann wrote:
My question is: What is really the benefit of having multiple packages in one directory? kahl@cas.mcmaster.ca has commented on this question, but his use case didn't convince me. Building many packages at once, an inter-package Make so to speak, would be nice, but this could be separate from the technique of building one package.
I can explain why the question occurred to me, but I'm a newbie to Haskell library construction, so I could have just set things up badly.
I have two libraries that both implement embedded domain specific languages in haskell, pads and forest, with forest depending on pads. Because they
Will pads be used on its own to the extent that it's painful to always get forest and pads together?
are both languages, I put the Pads modules in Language.Pads.XXX and the Forest modules in Language.Forest.XXX. I have a single development space with a directory Language with subdirectories Pads and Forest. Now I want to to be able to install these libraries with cabal. The place where it seems like I am supposed to put the cabal file is the directory containing the Language directory, but that means I need one cabal file for Pads and another for Forest. Rearranging my directory structure to separate the two packages is a pain because the files are under version control in CVS.
With more modern version control systems you can split a single repo into multiple repos, with the history for the files in the different repos intact.
I'm guessing I'm missing the right model for how to arrange Haskell source code bases. Suggestions for how I should do things differently?
Splitting things is often good, but sometimes it's easy to split things even when it's unnecessary. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus