Suggestion re altering the build system

[Andy Gill]

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
> Cvs-ghc at haskell.org
> http://www.haskell.org/mailman/listinfo/cvs-ghc
>