[kaffe] gerneral kaffe breakage (this time hp-ux)

[Dalibor Topic]

Ciao Riccardo,

Riccardo wrote:
> Hello,
> 
> I am sorry to announce that Dalibor's big fixing and merging effort has 
> currently quite made a disaster in kaffe build and portability. I hope 

 > make disaster
gmake: *** No rule to make target `disaster'.  Stop.

I haven't got around to fully implementing that yet, apparently ;)

> this is a temporarily situation and that the work will bring us a better 
> and more powerful kaffe in the future!

That's the idea! The road to fulfill that vision seems rocky at times, 
though, and ocassionally things seem to break down in transition ;)

> Current status with full reports is as always on
> http://homepage.mac.com/riccardo_mottola/kaffe-devel/
> or if my box is on
> http://multix.dyndns.org

Thanks for running the build tests regularly. Your effort is very 
appreciated.

Would it be possible for you to host the (compressed, bzip2, for 
example) build logs on your homepage?

> After the sad situation of 68k and sparc, the current victim is HP-UX. 

Looks like I got another one down, then ;) Though m68k netbsd was down 
for awhile, afaik, and sparc-solaris 9 worked for me with 1.1.3 
(actually even better than 1.1.2 or older releases, I think one or two 
less regression test failures). So not all is as bad as it seems to be 
on the debian buildd for 1.1.3, for example. ;)

> In this case it is the build that fails with the following:
> 
> In file included from ../../../kaffe/config/parisc/hpux/md.h:19,
>                  from ../../config/md.h:1,
>                  from ../../../kaffe/kaffe/kaffevm/classMethod.h:18,
>                  from ../../../kaffe/kaffe/kaffevm/support.c:33:
> ./../../kaffe/config/parisc/sysdepCallMethod.h: In function 
> `sysdepCallMethod':
> ./../../kaffe/config/parisc/sysdepCallMethod.h:56: break statement not 
> within loop or switch
> ./../../kaffe/config/parisc/sysdepCallMethod.h:61: break statement not 
> within loop or switch
> gmake[3]: *** [support.lo] Error 1

The break statements the compiler complains about were used to exit from 
the do {}while(0) loop of the macro. I didn't think about such use of 
break[1] when I converted the code to an inline function[2], so it 
remained in there.

Anyway, thanks for the bug report, I've checked in a fix into the CVS.

cheers,
dalibor topic

[1] I'd take if-else-if cascades any day, they can be factored out when 
necessary more easily.
[2] There should be refactoring tools for this.