-----Original Message-----
From: Russel Winder [mailto:[email protected]]
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
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
