To summarize, for easier reference:
- configure should warn about build tools with spaces in path
Ian has gone much further than that (great!-) and claims that such
warnings should now be unneccessary for most tools:
http://www.haskell.org/pipermail/cvs-ghc/2009-May/048887.html
- configure's summary should mention doc tools (xsltproc/dblatex)
- the build (or perhaps darcs-all) should check if mk/build.mk exists and is
older than mk/build.mk.sample. This should raise a warning, asking the
user to verify whether build.mk needs updating to follow build system
modifications.
- the call to windres in driver/ghci/ghc.mk needs a '-I driver/ghci' (or
perhaps
'--include-dir' instead of '-I'), adding the include directory so that the 'ghci.ico'
referred to can be found.
http://sourceware.org/binutils/docs/binutils/windres.html
I have no idea why this doesn't seem to cause failures for others - the windres
docs refer to the windows resource compiler docs, which state clearly that the
ICON path must be a full path or in the current working directory:
http://msdn.microsoft.com/en-us/library/aa381018(VS.85).aspx
or on a path named via '-I' or 'INCLUDE'
http://msdn.microsoft.com/en-us/library/aa381047(VS.85).aspx
- 'make binary-dist' fails for me:
http://www.haskell.org/pipermail/cvs-ghc/2009-May/048870.html
- MikTeX's dblatex doesn't appear to work for the job (no ideas on this one,
but since html/ps/pdf can be enabled selectively, and the first doesn't need
dblatex, it isn't a stopper for me)
- MikTeX's dblatex, when used for the first time, might download/install
missing packages, which would prevent unsupervised builds. It would
be good if that download could be triggered in configure, rather than
make (alternatively, perhaps the confirmation dialogue could be bypassed).
This is hampered by MikTeX apparently returning with an exit code that
suggests failure, even if the download was successful.
- build dependencies seem to appear somewhat coarse-grained in places,
causing unneccessary rebuilding of unaffected parts after minor changes
- there was also a segmentation fault in ghc 6.8.3, which doesn't repeat
when the build is simply restarted
Claus
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
