Isaac Jones writes:
[distribution vs. infrastructure]
You are right: Apparently we were approaching the issue from different sides. :-) My biggest problem so far is that there are numerous one-module libraries out there, which are very useful (DeepSeq, POpen, Shell-Haskell, etc.) and which require no "building" or "installation" at all. But it is very annoying to collect them and to keep the local copies up-to-date. Also, distributing them as part of my packages may cause license problems, users won't benefit from possibly available newer versions they have installed, and so on. But then I cannot distribute my package and expect the users do download a dozen small files from all over the Internet in order to compile it either. Solving _this_ problem is what motivated my proposal. Obviously, more complex libraries will occasionally require special pre-processors or multi-staged compilation, and then the build system issue will come back to haunt us. But this is rare; even fairly sophisticated code like HaXml or Functional MetaPost can be compiled with "ghc --make" or "hmake" without any problems.
- Despite being an open CVS tree, the approach is rather "cathedral".
I think it combines the best of both worlds: The "unstable" area serves as the bazaar, where people can do whatever they want. Whereas the "stable" area should provide production quality libraries. At the very minimum, the APIs of code in there should not change from one day to another.
- Some authors won't want to store a copy of their code on another CVS repository if their projects already have a home. This could cause redundancy and / or forking.
True. This is why I came up with cvssynch, so that the project could import code from other repositories in a semi-automated fashion -- without forking. But ultimately, it's up to the library author.
I'd be interested to see how your proposal fits with mine in your eyes.
From what I understand, your idea aims for something even bigger than mine: You'd like to have a tool infrastructure, which can retrieve, build and install pretty much any library for you, like the "ports" system of BSD Unix, right? I like the idea very much, and the two approaches are not mutually exclusive at all. Such a system could, for instance, easily fetch and build "hslibs" -- just like any other library it supports.
So maybe we're talking about two separate but related projects, actually?
Also, you mentioned hbuild, can you discuss how this improves upon hmake?
HBuild is going to be a full generic "make". The only difference to ordinary make tools is you don't write a Makefile, you write a Haskell program using a monadic combinator library, which you compile to get a project-specific build tool. You can think of "runhugs" to represent "make" and the Haskell source code to represent the "Makefile", if you want. :-) This is really work in progress, though. I'm having a lot of trouble coming up with a satisfactory design of the library, precisely because building software is so messy. (I already mentioned variant builds in an earlier post, for example.) Anyhow, HBuild is not really essential to the idea of the hslibs repository. (Neither is cvssynch.) It's just something I have been experimenting with ... Peter