[Haskell-cafe] Re: Gut Build System

2010-03-05 Thread Achim Schneider
Matthias Kilian k...@outback.escape.de wrote:

 On Fri, Mar 05, 2010 at 09:26:08PM +, 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-scale-introducing-ibb/
[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.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Gut Build System

2010-03-05 Thread 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.


Regards,
Malcolm

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: Gut Build System

2010-03-05 Thread Achim Schneider
Malcolm Wallace malcolm.wall...@cs.york.ac.uk wrote:

  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.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Gut Build System

2010-03-05 Thread Don Stewart
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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe