[M3devel] current tinderbox status, broken by me?

[Tony Hosking]

These result from inconsistency between the platforms defined  
statically in cm3 and the platforms declared in m3core.  You need to  
use the version in m3core that matches what you had when building  
cm3.  Then, extend cm3 before compiling the new m3core version.

On 30 Dec 2008, at 13:07, Jay wrote:

>
> NEXT    Fatal Error: bad version stamps: SocketPosix.m3
> 4678
> 4679          version stamp mismatch: Compiler.Platform
> 4680             => SocketPosix.m3
> 4681             => Compiler.i3
> 4682          version stamp mismatch: Compiler.ThisPlatform
> 4683             => SocketPosix.m3
> 4684             => Compiler.i3
> 4685  NEXT     *** execution of cm3 -build -DROOT=´/home/m3/work/cm3- 
> ws/birch.elegosoft.com-2008-12-30-01-00-04/cm3´ -DCM3_VERSION_TEXT= 
> ´d5.7.0´ -DCM3_VERSION_NUMBER=´050700´ -DCM3_LAST_CHANGED=´2008-03-16 
> ´  && cm3 -ship -DROOT=´/home/m3/work/cm3-ws/ 
> birch.elegosoft.com-2008-12-30-01-00-04/cm3´ -DCM3_VERSION_TEXT= 
> ´d5.7.0´ -DCM3_VERSION_NUMBER=´050700´ -DCM3_LAST_CHANGED=´2008-03-16 
> ´  failed ***
> 4686          compile return value: 0
> 4687          [end compile 2008.12.30 02:25:17]
> 4688          *** COMPILE FAILED
> No More Errors
>
>
> 1)
> Is it reasonable to suggest that the compiler output the source to  
> clashing definitions?
> Or is that a bogus naive suggestion?
> It is probably legitimate, at least to identify the files in question.
> Could be that not enough information is around to identify "what  
> changed", just some "summary hash".
>
>
> 2) Is it really broken?
> I did go slightly round and round on this.
> I had another new platform defined in one or another file and then  
> when I backed down and just did one reasonly finished platform, I  
> forgot at first to cleanup all the debris.
> But it certainly worked when I commited.
> I'm progressing on the native build, so if it is broken, I expect to  
> run into it myself.
>
>
> 3) Is it reasonable to annotate a type with some sort of "relax,  
> additions are safe" annotation?
> Probably not. It's probably too gray and more complicated than that,  
> since additions in general are not as safe as people thing. Adding  
> to a record -- folks might be copying based on the size and might  
> get back an older smaller version. Adding to an enum, folks might be  
> switching on it and expect to have the range covered. Adding a  
> function to an interface though, probably ok. Not the case here, and  
> perhaps not something the compiler even complains about.
> One that that might be eek-out-able is adding to an enum, and such  
> annotated types, switches on them must have an else clause, and they  
> must not be used for array indexing?
> Eh, maybe just leave it alone.
>
>
> Anything else? Is this just basically how it has to be?
> OR, how about, can the duplicity be eliminated?
> Like, can Compiler.i3 be fully generated by the compiler?
> Similarly, Csetjmp.i3 should be generated by the compiler, eh?
> Or at least partly? You know, the size and alignment of the jmp_buf  
> is recorded in both Csetjmp.i3 and Target.i3. Duplication is  
> generally bad imho