build system issues

[Simon Marlow]

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