Version control systems

[Johan Henriksson]

Don Stewart wrote:
> kili:
>   
>> On Mon, Aug 11, 2008 at 04:17:59PM +0100, Simon Marlow wrote:
>> [...]
>>     
>>> As for Cabal - we had a thread on cvs-ghc last week, and as I said there
>>> we'd love to hear suggestions for how to improve things, including wild 
>>> and crazy ideas for throwing it all away and starting again.  However, as 
>>> I explained, there are good reasons for the way things are done now, the 
>>> main one being that the build system for packages is not written twice.
>>>       
>> Well, at least the Makefile creation was a step (the first step?)
>> into the wrong direction, IMHO. I'll run a GHC build to get some
>> of those generated Makefiles and followup on cvs-ghc, but for a
>> starter, Cabal shouldn't know anything about implementation-specific
>> internal build systems; instead it should rely only on it's own
>> metadata.  Implementation-specific stuff (such as how to run the
>> compiler) should be supplied by the implementation, not by Cabal.
if we're going to kick on cabal I might throw in my two cents.

I see an increasing problem in that every community comes up with their
own package system, instead of reusing existing frameworks. dependencies
to other non-haskell libraries has to be addressed for every other
coexisting package system (such as apt-get), if it is addressed at all.
likewise, other languages depending on haskell will have trouble
resolving dependencies.

so my point is, if there will be any bigger reworking of cabal, I think
one should consider how it could work as a module in a bigger (maybe
future) meta-packaging framework, lifting up binaries to for example
.deb, .exe-installer, .dmg or whatever is the most native for the
platform. I see a point in language specific package systems as they
have more insight into the build process, but the current
implementations assume a very ideal world in which there are no other
dependencies involved.

/Johan