FW: Building GHC HEAD

[Simon Marlow]

> -----Original Message-----
> From: Russel Winder [mailto:russel.winder at concertant.com]
> Sent: 11 May 2009 09:16
> To: Simon Peyton-Jones
> Cc: Simon Marlow
> Subject: RE: Building GHC HEAD
>
> (Actually the page
> http://hackage.haskell.org/trac/ghc/wiki/Building/Using doesn't really
> give me enough detailed process information to be confident of what to
> do to create and use multiple build trees.  I infer that actually
> Haskell doesn't separate the notions of source and build tree, you just
> have a tree and you have to copy the whole thing to a separate root for
> a separate platform.  It just happens that Unix links or symbolic links
> are a way of doing this without having multiple copies of 350MB of
> stuff.)

Yes - but why make things more complex than they need to be?

> The problem here is that the build assumes it takes place in ./inplace
> which is a fixed name and not platform dependent -- big error !

./inplace is just where the final binaries end up, so you can easily use 
the results of the build without having to search the build tree for 
executables.

If you're using multiple build trees, then each one would have a single 
build for a single platform.

> The current solution is very Unix oriented, workable, but . . .
>
> Could you just mandate GNU Make and use VPATH as a way of handling
> remote source trees?

In my experience VPATH never works right.  In fact, I'm not sure I even 
understand what it does.  Our build system is complex enough without 
adding VPATH to the mix!  We have multiple builds per source directory 
already (e.g. GHC is built multiple times per build, and packages are 
built multiple ways).

Why add special support for multiple build trees to the build system, 
when lndir does the right thing and costs nothing?

> A neater solution assuming the necessity to copy the entire tree would
> be:  Use Bazaar to create a master mirror of the source then use
> lightweight checkouts to create new working trees for each architecture.
> Saves the hassle of using commands that have to be held in the Haskell
> source tree.  (Git can do something similar, and I am sure Mercurial
> will be able to soon as well.  I appreciate that Haskell is basically
> tied to Darcs in perpetuity,

Not at all!  We already decided to switch to git, although we may 
re-evaluate that decision.  We're not tied to any particular VC system. 
  However, the fact that our sources are in multiple repositories does 
make it tricky to switch. See

http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation

darcs with hashed repositories can duplicate trees pretty quickly. 
We're a bit behind the darcs curve and aren't using hashed repos for our 
main repos, but there's nothing stopping you using hashed repos locally. 
  Then you can have one copy of the patches shared by all your local GHC 
repos, transparently.

Cheers,
	Simon