Hi Simon,
I understand the need to have a HEAD that works most of the time.
But the question "How do I get a recent copy of HEAD, that works(*)"
seems reasonable.
I wanted to fellow galois engineer to try something in HEAD, and he
needed to give
up before he got a working build.
(*) where works == definition below.
My suggestion (after taking input from #ghc and #darcs) is
* Having a web page that contains the contexts (or hash numbers)
of the various darcs repos that went into making the latest
good build.
* This page also contains the darcs gets commands you type
to get this working copy.
In this way, I can reliably get a working copy, for trying out things
in HEAD.
Of course, we need a very recent copy of HEAD if we want to actually
push changes back into the master repo.
AndyG
On May 29, 2007, at 8:08 AM, Simon Peyton-Jones wrote:
| > Nevertheless, I don't think I am alone. For example, not long
ago I met
| > Andy Gill in #ghc trying to find a version of the head that's
fairly
| > recent and still builds.
| >
| > So, let me make a suggestion. Could the changes to the build
system
| > maybe done on a branch of the repos and be integrated into the
live tree
| > in larger intervals? Then, we'd have the pain in bursts, but less
| > often. I appreciate that this is not entirely trivial as you
have to
| > branch the packages along with the ghc repo, but the current
situation
| > is extremely frustrating.
|
| I feel your frustration, stability of the HEAD does seem to have
been a problem
| of late.
Beyond what Simon has said, I'd like to be clear that we regard it
as a priority for a clean build to go through, at least far enough
to have a working compiler and libraries (even if some tests fail).
If that does not happen for you, do not wait long before
complaining (politely, of course). Ian, who is the person who's
being doing most work on the build system of late, can't fix things
if he doesn't know they are going wrong. And maybe he'll see a
common pattern emerge! Do not simply suffer in silence.
It's best of all if you can offer a definite cause, but even the
mere fact that "darcs pull; make" didn't work (plus the tail of its
output) is useful information. Within reason we want "make" to
rebuild whatever is necessary. When the build system itself is
changing that's hard to ensure, but we can help each other by
sharing problems and solutions.
Furthermore, even if you find a solution, it's good to explain what
happened and how you fixed it. Ian may be able to use that info to
make the build system more robust, or at least to produce a more
helpful error message.
Suggestions for how the build system itself could be improved to be
more robust would also be good.
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
