Brian Hulley wrote:

To port GHC to a completely new platform, you'd of course need a Haskell compiler or interpreter already. However to bootstrap the process only a slow interpreter would be needed so as long as a portable pre-built bytecode version was available for download the only thing left to port would be a byte code interpreter which could just be a single file of c code.

This was one void Yhc was designed to fill, especially by compiling to java bytecode. At the rate I work--if I'm the only one deconstructing the current build system--by the time I'm done the Yhc team will have everything running. Greg Fitzgerald wrote:

I was trying to build something like this recently but hit a roadblock. ... Unfortunately, the imported module needs to have the line "module X.Y.Zwhere", which means the file needs to be aware of its parent directories. I think that's too harsh a constraint, and makes it a pain to move things around (true in everyday Haskell projects with local modules too!).

Have you looked at Neptune? It is a scriptable build system based on Jaskell, which allows dynamic imports. An example from the page at http://jaskell.codehaus.org/Jaskell+for +Neptune#JaskellforNeptune-90: //in script1.jsl 1+x where x = import {file="script2.jsl"}; end You may imagine that the string for "script2.jsl" may be computed. Of course this sort of thing breaks the type system in Haskell and the result is more Make-like, but that is the tradeoff. Now why did I not try a build system using Neptune? Probably because I had already spent the last three weeks learning CMake, the pecularities of SCons, WAF (weird bugs!), m4 (I never had to write tests in Autoconf before or debug my own configure files), and higher level Make (so it would do what I can do in Jam)--I guess it got lost by the wayside... I was looking at things most people would either already know or would want to learn and that should already be available on new platforms. skaller wrote:

The second is simply that dynamic typing is generally better for build systems, because it allows code to 'self-adapt'.

There is a somewhat slow-going scheme-based-build-system project called Conjure, at http://home.gna.org/conjure/ but it only supports Linux and OS X.

An alternative is to implement the build system in, say, Scheme, and then write a Scheme interpreter in Haskell. Scheme can self-adapt internally because its compiler is built-in.

That is why I was looking into using SISC--it is self-contained and may even be distributed along with the source code (SISC itself is GPLv2 but that doesn't matter for _using_ it)--by default it looks in the current directory. The downside is the lack of a library with directed graphs. Cheers, Pete