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