> On Fri, Mar 05, 2010 at 09:26:08PM +0000, Simon Marlow wrote:
> > >Switching GHC to a completely new build system written completely
> > >in Haskell would be the most stupid idea ever. (You know why)
> > You're referring to bootstrapping, I presume?
As it stands, GHC can't be bootstrapped without a GHC, anyway. I'd love
to see GHC bootstrapping from C, e.g. via hugs, though. (A man is
allowed to dream)
> > I did think about mentioning that. Of course any Haskell build
> > system would have to support cross-compilation or some other
> > bootstrapping method, e.g. generation of a build script.
> That's a noble goal. But it has to be kept in mind.
This may be fairly easy, if the generated script does not have to come
with major build-system capabilities: Leaving out most of dependency
analysis and support -- at the utmost -- restarting a failed build from
the rule whose source file has last recently changed, otherwise
compiling in a linear order deduced at script generation time should
reduce the problem to serializing the actions generated for a clean
build to a shell script.
I'm cross-posting this to the cafe and suggest that most if not all of
this discussion be done there as most of it doesn't specifically relate
to GHC. And there might be volunteers amidst the crowd.
That said, I'd very much like to see a make-replacement done in
Haskell, there's not only place for a properly-scriptable make, but
also sufficient room for general innovation:
Omake would be even better if it wasn't scripted in some ad-hoc,
impure, incomplete ocaml dialect but in a decently pure functional
IBB sound like a feature we'd definitely want to have (thanks for
the link, Thomas)
I'd also like to point to Nix and Cabal for ideas, and I bet most
of the dependency analysis could be ripped from the latter.
I think we can do vastly better than the whole SCons/CMake/Jam crowd.
> > I'd also like to point to Nix and Cabal for ideas, and I bet
> > most
> > of the dependency analysis could be ripped from the latter.
> Hrrm, sadly Cabal has no dependency analysis at all - everything
> must be specified by the author of the .cabal file, both modules and
...with analysis I mean figuring out what needs to be done, with that
data as the basis. You're right, of course.
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.
>> I'd also like to point to Nix and Cabal for ideas, and I bet
>> of the dependency analysis could be ripped from the latter.
> Hrrm, sadly Cabal has no dependency analysis at all - everything must be
> specified by the author of the .cabal file, both modules and packages.
I could imagine a 'cabal inspect' command that checks the .cabal file
against what the repo actually needs might be somewhat useful.