Re: hmake 3.09

On Fri, Nov 19, 2004 at 11:10:20AM +0000, Malcolm Wallace wrote:
> > I happened to notice a new release of hmake was out - thanks for doing
> > this!
> 
> Well, it is packaged, and so is cpphs-0.8, but they are not yet
> announced properly.  I was hoping to announce refreshed releases of
> hmake, cpphs, and nhc98 all at the same time,

Ah, better still!  :-)

> but unfortunately the
> Cygwin build of nhc98 is currently seg-faulting about 50% of the time,

:-(

> hence only the other two tools have managed to make it out so far.

Speaking of nhc98 problems, when building hat on sparc I'm getting

$ nhc98   +RTS -H32M -K2M -RTS +CTS -H32M -CTS  -I. -I../compiler98  -c  -o /scratch/igloo/hat/hat-2.02/debian/build-nhc98/targets/sparc-Linux/obj/hattrans/HbcOnly.o ../compiler98/HbcOnly.hs
Ratio.%: zero denominator
$ 

and the same with 16M instead of 32M, but with 20M it (this file -
haven't tried further) compiles fine. Does this sound like a heap
corruption bug, or have you got any other idea of what might cause it?
Has anything changed in CVS that might have fixed it?

> > However, unfortunately it seems that the patch I sent here:
> > http://www.haskell.org//pipermail/nhc-users/2003-September/000099.html
> > didn't make it into CVS  :-(    I've attached the patch for 3.09 (it has
> > a few other small tweaks I made too).
> 
> I must apologise.  I do have a stack of suggestions for improvements
> to hmake in my inbox, but have not really had the time to review
> or implement them properly.

No problem, understood - I could do with some more hours in the day
myself  :-)

> > In src/hmake/Imports.hs does "stringgap (c:cs)    = stringgap cs"
> > deliberately not check isSpace c? Hmm, there's no [] case either.
> 
> Is it unreasonable to assume that the Haskell file is syntactically
> correct?

If you are hacking on something whose Makefile uses hmake then I don't
think you can be confident the source is always syntactically correct.
Well, maybe yours is, but mine isn't  :-)

> I suppose for robustness of hmake, we should at least have
> the [] case, but I don't know what the right thing to do is if the
> gap contains non-white characters - currently it ignores them, but
> it could throw an error.

Ah, I guess the compiler will give a suitable error anyway if the gap
contains illegal characters, so not checking seems reasonable. Handling
the [] case would definitely be good, though.


Thanks
Ian