To clarify: Maybe I should have pointed out more explicitly in this message that I *do* understand that Hugs is an interpreter, and doesn't produce object files, or compiled packages. I understand how Cabal works with GHC and Hugs. My question, why a build system is needed to abstract away their differences, has yet to be addressed. It could be that the answer is simply that it was thought that the current way of doing things would just be more convenient, but in any case I think the question should be addressed and not evaded. A build system is something that manages dependencies between and schedules the execution of commands. I see no reason why all Haskell compilers and interpreters could not be given an standard interface which (1) provides a way to find dependencies of sources (2) provides a way to execute all the necessary commands supported by Cabal, so that any build system could be used with any compiler to build any Haskell code, and do what Cabal does now. Furthermore, I would like to point out that this issue may have much greater importance in Haskell than in other languages, due to the fact that it is hard to imagine a standard Haskell ABI. In C, one can compile ELF libraries with different compilers (I think) and still use them in the same application - this is the layer where the standardization exists. Haskell, on the other hand, needs to have library and executable compiled with the same compiler, or interpreted with the same interpreter. It is good of the Cabal people to recognize this need and address it, but I'm inclined to think that a light-weight compiler interface would be more appropriate as a standard, than one which is tightly coupled with a build system. Note that I'm not suggesting Cabal be abandoned - it would be possible to develop a compiler interface standard, and modify Cabal to use it. Cabal would become much simpler; conforming to the standard would become the task of individual compiler developers. Frederik On Sun, Sep 04, 2005 at 02:15:12PM -0700, Frederik Eaton wrote:
By the way, as I've been thinking about Cabal, I remembered this question to which I haven't found an answer. I realize that I haven't been party to the initial discussions, but John Meacham didn't know the answer either, so I will ask it.
As I understand it, Cabal is meant to provide people with a compiler-independent way to build Haskell packages. So it (a) builds packages while (b) abstracting over compiler interfaces. Why was the decision made to couple these two functions into a single project? It seems to me that maybe having two separate projects would be more manageable and useful.
- The first project would provide a standard command-line interface to Haskell compilers. There would be operations such as: compile a file into an object file (may be a no-op); link a bunch of object files into a package; install a package into the following package database; create an empty package database; merge two package databases; find dependencies of a module. And options like: use the following other packages, search for packages in the following package database. Basically, the things that compilers can do, but given a standard interface.
- The second project would provide a build system. I guess there would be a lot of options here. There seems to be a demand for a system with some main declarative specification file which can be processed by external tools to find out what dependencies a project has on other projects, etc., which Cabal is responding to. So perhaps people would write something like this. However, if there were two separate projects, then developers would also have the freedom to use a build system like 'make', or something more sophisticated and unforeseen, with the generic compiler interface as well.
By decoupling the standard compiler interface and the build system, one would be able to make improvements independently to each one. Design and development would be faster, users would have more choices, it would be easier to experiment with new versions of each project.
So, back to my question. Why couple the two?
Frederik