[M3commit] CVS Update: cm3

[Tony Hosking]

We need standalone tools for bootstrapping reasons.  I always have  
multiple versions of cm3 around when extending/debugging/bootstrapping  
the compiler and I don't want them breaking when I ship a broken  
runtime!

On 26 Jun 2009, at 09:07, Jay wrote:

>
> ok, I think it is fairly redundant with cm3cg -y, but I can see,  
> just tried it, it is much more informative.
> I should use it instead of cm3cg -y and instead of extending cm3cg,  
> except, in an extremely bad scenario, if cm3cg reading the file had  
> a bug, then you'd cross check cm3cg -y with cm3cgcat.
>
>
> Still it isn't need in "core"/"base" though, almost nobody uses it.
> I was looking at this because I was looking at what was in the  
> install archives
> and found m3cggen and cat in core.
>
>
> But also..an old m3cgcat should generally do?
>
>
> My metric for something needing to be built standalone is/was:
>  cm3, for some more and less clear reasons
>    A non-standalone cm3 cannot ship m3core and libm3 on some  
> systems, clear.
>    And if you were to build m3core and then copy it "manually", en  
> route to building libm3,
>    you'd put the compiler in an inconsistent intermediate state.
>
>    I used to have in mind something related to an old cm3 being  
> possibly unable to
>    build a current m3core/libm3, like with the LONGINT change, but I  
> don't see that now.
>
>    The ship-in-use reason can be worked around really. You'd just  
> buildlocal and then
>    override the inability to ship builtlocal by just copying the  
> file. We copy it currently anyway.
>    Though we ship the manpage.
>
>    Which leads me to actually ask -- why must cm3 be standalone?
>
>
>  Anything for which an unshipped copy is run out of the workspace,  
> where the "runpath"
>   isn't correct. Like m3bundle and the rpc stub generators.
>   Actually these are already a special case -- having to mark them  
> standalone --
>   probably a better special case is viable...well..it strikes at the  
> notion really
>   that the unshipped/shipped difference is imho implemented  
> incorrectly.
>   An alternative would be "shipped here or shipped there", always  
> ship somewhere,
>   but generally to a new install root, and once it seems good and  
> working, then either
>   move or copy everything to the "real" place. If you've built  
> "everything", this
>   resolves to deleting the old and renaming the new root.
>
>
>  That is, stuff that has a reason independent of bugs, as a matter  
> of course,
>   where it fixes things in the normal automated processes, including  
> bootstrapping
>   from an older build (which I thought made a difference but I don't  
> see now).
>
>
>  You know, sometimes I break my cm3. In which case I go back to an  
> old one.
>
>
> - Jay
>
>
> ________________________________
>> From: hosking at cs.purdue.edu
>> To: jkrell at elego.de
>> Date: Fri, 26 Jun 2009 08:31:22 -0400
>> CC: m3commit at elegosoft.com
>> Subject: Re: [M3commit] CVS Update: cm3
>>
>> Yes, this needs to be standalone because it is used in debugging  
>> the compiler and libraries. If they change in bad ways then it will  
>> break.
>>
>> On 26 Jun 2009, at 10:12, Jay Krell wrote:
>>
>> CVSROOT: /usr/cvs
>> Changes by: jkrell at birch. 09/06/26 10:12:42
>>
>> Modified files:
>> cm3/m3-sys/m3cgcat/src/: m3makefile
>>
>> Log message:
>> This doesn't need to be standalone.
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20090626/c0373211/attachment-0002.html>