[M3commit] CVS Update: cm3

[Jay]

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