build system issues

[Claus Reinke]

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