[M3devel] current tinderbox status, broken by me?

[Jay]

Ah, I thought the Tinderbox always ran upgrade.sh first.
 
 - Jay


----------------------------------------
> Date: Tue, 30 Dec 2008 11:01:24 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] current tinderbox status, broken by me?
>
> 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 :
>
>>
>> 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
>