Re: How about change prep-bin-dist-mingw's default enviroment up todate?
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 23 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' ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: How about change prep-bin-dist-mingw's default enviroment up todate?
Claus Reinke wrote: 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' http://hackage.haskell.org/trac/ghc/ticket/937 This fix will be in 6.6.1. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: How about change prep-bin-dist-mingw's default enviroment up todate?
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' http://hackage.haskell.org/trac/ghc/ticket/937 This fix will be in 6.6.1. great, thanks! that almost makes my suggestion for ghc --print-docdir obsolete. perhaps the users guide should be a documentation package, but then its html is not haddock-html, so --print-docdir is needed after all. btw, is there a reason that --simple-output only applies to 'list'? i had hoped it would apply to 'field', too, giving only the field value (actually, it does seem to apply beyond 'list' in a recent head, but still not to 'field'). claus ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: How about change prep-bin-dist-mingw's default enviroment up todate?
prep-bin-dist-mingw supports to bundle GHC Windows binary distribution
with cc1plus.exe, now.
But prep-bin-dist-mingw assumes that GHC is build by MinGQ version 3,
Does anyone know whether or not this script is still used? It looks like
it contains a number of out-of-date values, and doesn't seem to be
called by the Windows nightly builds. I don't know about the Windows
installer.
Sigbjorn would be the right person to ask, I guess?
as a windows user, i have very much depended on prep-bin-dist-mingw, whenever
i want to convert my inplace GHC into something resembling the snapshots/releases.
i haven't done that for a while, because i tend to wait for the nightly builds to go
through without hitches, but i'd certainly miss that feature.
and i thought that whoever intoduced the recent version-in-path changes hasn't
gotten
around to updating the windows builds, which looked like the reason for the ongoing
failures in the nightly builds since then:
building compiler binary distribution... failed.
canonicalizing mingw binary distribution tree... failed
(ghc-6.7.20070312 not found).
but if you say it isn't used anymore, what is the current recommended way to
create an installer-free bundle of a working self-compiled GHC on windows,
and why does the distribution stage keep failing?
once upon a time, i suggested to extract the relevant information from the
configure info, instead of the current hard-coded values/paths, but while it
is fairly easy to get info from GHC's configure
http://www.haskell.org/pipermail/cvs-ghc/2005-May/025075.html
that idea was somewhat naive - the real problem are the changes in
directory layout within gcc/mingw et al.
unless one can query gcc about its directory structure (??), the script
keeps having to be adapted by hand for different versions, which means
that someone has to decide that their build environment needs updating,
which isn't likely as long as it works, and that someone has to invest
time into figuring out what changes such an update implies for the script
(and i tend to dread updating my working system whenever someone
updates the script, because by the time that change reaches me, i might
update to a version of gcc/mingw with new problems/dependencies..).
but of course, there are new windows GHC users, and those who like
to keep their mingw/gcc uptodate, and that group doesn't like the old
values in the script.. perhaps one could accumulate known mingw/gcc
configurations, and make the script select the appropriate one based
on version info..
claus
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
