On 02/06/2009 12:31, Claus Reinke wrote:
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)
now done.
- 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
Could you make this change, test it, and submit a patch please?
- 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.
I don't think there's much we can do about these.
- build dependencies seem to appear somewhat coarse-grained in places,
causing unneccessary rebuilding of unaffected parts after minor changes
Please supply concrete examples - we're keen to try to improve this sort
of thing where possible. I did look into the config.mk case you
mentioned, and made some slight tweaks as a result.
- there was also a segmentation fault in ghc 6.8.3, which doesn't repeat
when the build is simply restarted
Again, not much we can do about that. I'm surprised it's so
reproducible though.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
