Matthias Kilian
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?
Yes.
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[1] would be even better if it wasn't scripted in some ad-hoc, impure, incomplete ocaml dialect but in a decently pure functional language; IBB[2] sound like a feature we'd definitely want to have (thanks for the link, Thomas) I'd also like to point to Nix[3] and Cabal[4] 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. [1] http://omake.metaprl.org/index.html [2]http://chadaustin.me/2010/03/your-version-control-and-build-systems-dont-sca... [3] http://nixos.org/nix/ [4] You know where. -- (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[3] and Cabal[4] 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 packages. Regards, Malcolm
Malcolm Wallace
I'd also like to point to Nix[3] and Cabal[4] 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 packages.
...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.
malcolm.wallace:
I'd also like to point to Nix[3] and Cabal[4] 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 packages.
I could imagine a 'cabal inspect' command that checks the .cabal file against what the repo actually needs might be somewhat useful. -- Don
participants (3)
-
Achim Schneider -
Don Stewart -
Malcolm Wallace