[M3commit] CVS Update: cm3

[Jay]

Ah, multiple copies of cm3 only, perhaps in the "real" directory, but no extra copies of libm3/m3core/sysutils? That makes some sense, but if it is just for your/my sake, just put them in separate directories? You know, runpath is now $ORIGIN/../lib, not /usr/local/cm3/lib, so you can move directory trees and "the tree is standalone" (except on NetBSD and systems I haven't gotten to, like AMD64_DARWIN).
 
You know about that?
Does that suffice?
 
 
(Granted, by default, you get both $ORIGIN/../lib and /usr/local/cm3/lib. $ORIGIN/..lib comes first. The distributed versions only have $ORIGIN/../lib. This is a compromise so that users can generally run built-locally unshipped binaries. Anyone intending to copy binaries from the build machine to another machine should set CM3_PORTABLE_RUNPATH or such like make-dist.sh does, to limit runpath to just $ORIGIN/../lib. I guess that needs documentation in an advanced section.."how to distribute your Modula-3 binaries".)
 
 
Is it just for us introducing temporary bugs, or does building from an earlier release really require it?
 
 
It is even tempting to set runpath to just $ORIGIN and put the libraries in the bin directory.
That's what NT386 does.
It's just slightly bad for users going looking for what things they might want to run and they see all those extra files.
 
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Fri, 26 Jun 2009 09:21:59 -0400
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
>
> 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.
>
>