[M3devel] current tinderbox status, broken by me?

[Olaf Wagner]

This is a known problem; see http://www.opencm3.net/known-problems.html#p_1_5
for details. It occurs whenever you add or remove target platforms.

It is exactly what the last-ok build was made for :-)

As for your other comments, I would appreciate if the compiler would
output the exact conflicting file paths, but I believe that the
information is not easily available at that point.

Olaf

Quoting Jay <jay.krell at cornell.edu>:

>
>  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



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194