How about change prep-bin-dist-mingw's default enviroment up todate?

[Claus Reinke]

> The nightly builds are moving to BuildBot (in case you hadn't noticed).  We have 4 Windows builds 
> in BuildBot: nightly HEAD/6.6 and fast HEAD/6.6.  Currently I'm not building any distributions 
> from these builds, but I'd like to.

thanks for the update, Simon. there are many things i get out of the old nightly builds:

    1 is the current darcs version buildable on windows, or where does it go wrong?
        - this means that patchers can check whether they have broken the windows
            build, and hopefully go on to unbreak it quickly
        - this also means that i do only set out to build GHC from source when i'm
            confident that it should build successfully (with a darcs pull on the day after
            a successful nightly build)

    2 nightly snapshots, which i can download myself or, more importantly, ask others
        (who run into trouble with the official release but don't use darcs) to download

    3 a script (right in ghc's darcs repo) to build installer-free snapshots that
        correspond 1-1 to nightly snapshots and releases, replacing the installer
        by a simple bundling of files

the current BuildBot setup seems to cover only 1, so yes, please, reintegrate 2&3
as well before stopping the old-style nightly builds.

> Sigbjorn is running a Windows nightly build using the old nightly build scripts 
> (http://darcs.haskell.org/nightly), and building a snapshot distribution which is uploaded to 
> haskell.org.  The distribution is built using the prep-bin-dist-mingw script (see the nightly 
> scripts).

http://darcs.haskell.org/ghc-nightly/bin/nightly-wrk

ah, thanks. that is the part of your scripts i was missing!-)

that is also the script responsible for the current failures in nightly builds, then?

> Ian: I think http://hackage.haskell.org/trac/ghc/ticket/1093 might still be wrong, because the the 
> prep-bin-dist-mingw script puts the docs in the "doc" subdirectory but doesn't update the 
> haddock-html fields.

do i understand correctly that the current oddities are the result of scripts fighting
about where to copy things, but that, ideally, i should get the precise location of
installed haddocks by concatenating the results of ghc --print-libdir and
ghc-pkg field base haddock-html (after filtering out garbage like $topdir and
haddock-html:)?

claus

ps there has to be a less ugly way to get the doc path than this, though:
    ghc-pkg field base haddock-html | sed -e 's/^[^:]*: //' -e 's/$topdir/echo 
`ghc --print-libdir`/e'