<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>There is a problem here.<BR>Something I also want to do is stop building things standalone, on NT and systems that support "origin", which is pretty much all of them.<BR>The problem .. I'm alluding to two solutions.<BR> <BR> <BR> 1) "run from" and "install to" are the same <BR> 2) or different <BR> <BR> <BR> But we also want "atomic" update of cm3 and its dependencies (m3core/libm3). <BR> #1 only works if the old and new are compatible-enough.<BR> #1 is more automatic <BR> <BR> <BR>I think the answer is, if you are rebuilding m3core/libm3/cm3, and the old and new are not compatible-enough, you must set the output to be a new empty directory, and "run from" and "install to" must be different. If you are building almost anything else, you can safely update in place w/o breaking the compiler.<BR> <BR> <BR>We might be able to achieve all of this by setting BUILD_DIR to an absolute path.<BR>But I think I really want it driven by environment variables and not config files.<BR> <BR> <BR>Before I do anything here, it looks like we could cleanup the m3overrides files in the current tree.<BR>I did a lot of it already, years ago now, but some remains.<BR>And then replace that system, is my proposal, with "override" not doing/meaning anything ever.<BR> <BR> <BR>One more problem..do people here do, like "do-cm3-all build && sudo do-cm3-all ship".<BR>Is it ok if this becomes "do-cm3-all build && sudo cp -r something1 something2"?<BR>You know in GNU build system parlance, if build implies make install DESTDIR=writable-by-non-root.<BR> <BR> <BR> - Jay<br><br><br> <BR><div><hr id="stopSpelling">From: jay.krell@cornell.edu<br>To: rodney.m.bates@acm.org; m3devel@elegosoft.com<br>Subject: RE: [M3devel] propose "output root" to replace shipping<br>Date: Tue, 24 Mar 2015 08:19:06 +0000<br><br>
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">The point is, kind of to make it better, by making it worse.<br>Or worse by making it better.<br> <br> <br>In particular, "ship" would go away.<br>Files would <em>always be overwritten right away</em>.<br> <br> <br>If you don't want this -- and indeed <em>sometimes </em>you don't, you<br>would change the output root to a new empty/nonexistent directory,<br>possibly copying all of the previous into the new.<br> <br> <br> <br>cm3 and its dependencies would require special attention.<br>In particular, for sharing violations on .dlls, we'd rename away and copy back.<br>Does that then work on all systems? It works on NT.<br>I'm betting most Posix systems "just work" and AIX requires either the same as NT<br>or can't be made to work so easily.<br> <br> <br>If the outputs are bad, you would have to restore from backup, for things like cm3/m3core/libm3 (and<br>basically just them). For anything not used by cm3, just edit the source and recompile again.<br> <br> <br>You could view this as taking away an escape hatch.<br>But a simpler easier to understand escape hatch remains.<br> <br> <br>And the escape hatch is really only critical for cm3 and its dependents.<br>Or "build tools" maybe more generally, like klex, kyacc, m3bundle.<br> <br> <br>Is this still the mailing list to use, or something new with git?<br> <br> <br>Now -- another use of "ship" is "install" not on the same machine as compile.<br>For this, I propose, just un-tar-gz or unzip instead, or recursive copy if not archived.<br> <br> <br>A background point here is -- have fewer different directory layouts.<br>Instead of ship rearranging stuff, just arrange stuff when you link in the first place.<br> <br> <br>This would also argue that the source tree and install tree should be more-similar/identical<br>except for the root, but I'm reluctant to rearrange the source..even to lift up the "src"<br>leaves by one, in order to keep the tree diffable against old trees.<br> <br> <br> - Jay<br><br><br> <br><div>> Date: Sun, 22 Mar 2015 11:57:35 -0500<br>> From: rodney_bates@lcwb.coop<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] propose "output root" to replace shipping<br>> <br>> I haven't had time to digest your proposal yet, but I have often been uncomfortable<br>> about the current build system when building/bootstrapping itself. It is probably<br>> just lack of understanding of the right procedure, but I usually cringe before attempting<br>> to bootstrap. I have always been unclear about the sequence of when the newly built<br>> components overlay the preexisting ones, so I would welcome some attention to this.<br>> <br>> I would like to put in a vote for a way to build everything without overlaying<br>> any existing components, so a bootstrapping operation can be easily restarted back<br>> where it started. Right now, for the compiler itself, I am meticulously saving side<br>> copies of the compiler executables in /usr/local/cm3/bin every time.<br>> <br>> On 03/20/2015 07:10 PM, Jay K wrote:<br>> > Building the current system fails in caltech-parser\parserlib\parserlib\test.<br>> ><br>> ><br>> ><br>> > It tries to run an shipped klex but only the non-shipped one exist -- depending on the state of things.<br>> > But even if shipped exists, it likely shouldn't be using it.<br>> ><br>> ><br>> ><br>> > This is a general problem we have been through somewhat before.<br>> ><br>> ><br>> ><br>> > There are multiple parts to our current partial solution:<br>> ><br>> ><br>> > They can be seen here:<br>> > C:\dev2\cm3\m3-comm\netobj\src\netobj-ov.tmpl<br>> > C:\dev2\cm3\m3-comm\sharedobj\src\sharedobj-ov.tmpl<br>> > C:\dev2\cm3\m3-libs\libm3\src\bundleintf\bundle-ov.tmpl<br>> > C:\dev2\cm3\m3-ui\zeus\src\m3zume-ov.tmpl<br>> ><br>> ><br>> > And those various "build tools" use build_standalone()<br>> ><br>> ><br>> > This could imho be abstracted.<br>> ><br>> ><br>> > However, I propose where today we have:<br>> > source_root/m3-foo/bar/target/abc.obj<br>> > source_root/m3-foo/bar/target/bar.exe<br>> > source_root/m3-foo/bar/src/abc.m3<br>> ><br>> ><br>> > we instead have:<br>> > output_root/obj/bar/target/abc.obj<br>> > output_root/bin/target/bar.exe<br>> > output_root/bin/bar.exe link or stub to target/abc.exe<br>> > output_root/pkg/bar/...<br>> ><br>> ><br>> > or:<br>> > output_root_obj/bar/target/abc.obj<br>> > output_root_install/bin/target/bar.exe<br>> > output_root_install/bin/bar.exe link or stub to target/abc.exe<br>> > output_root_install/pkg/bar/...<br>> ><br>> ><br>> > and that "install" become just directory operations, like deleting old and move or copy output_root{_install} to it<br>> > just "script", not anything in cm3,<br>> ><br>> ><br>> > and then, on systems that support "origin" -- NT, Linux, Solaris, FreeBSD, NetBSD >= 5.0, we don't<br>> > use standalone for this, and on systems that don't support "origin", still use standalone<br>> ><br>> ><br>> > and then shipping goes away, as a package operation.<br>> > you can instead ship an output root.<br>> ><br>> ><br>> > and then this override stuff goes away also;<br>> > You bootstrap by copying in a few working files. Like make-dist.py does.<br>> > The system is reduced in size, as build_standalone falls away -- you can still use it,<br>> > but it won't be used usually.<br>> ><br>> ><br>> > The larger source tree would become readonly, as it should be.<br>> ><br>> ><br>> > Thoughts?<br>> ><br>> ><br>> > I believe Modula-3 was originally ahead of its time in having the readonly src directories,<br>> > but I believe time as passed it by, and what one really wants is a larger readonly tree of src directories/packages -- which<br>> > might as well not say "src", but preserve that instead of rearranging everything.<br>> ><br>> ><br>> > I know, I've heard, having the separate buildlocal / buildglobal is useful.<br>> > This doesn't elimine it that.<br>> > It replaces it with "multiple buildglobal".<br>> > Instead of having just the two options -- local and global -- you can create an arbitrary number of<br>> > "global" scopes by creating a new output_root, copying it from a preexisting one.<br>> ><br>> ><br>> > As well, it is obscure, but you can also have "multiple local" by changing BUILD_DIR.<br>> > But I don't think anyone does that. I think everyone leaves BUILD_DIR == TARGET.<br>> ><br>> ><br>> > This has several nice properties.<br>> > readonly source tree<br>> > less file copying possibly (depending on if final scripted ship is directory copy or move)<br>> > cm3 can stop implementing ship<br>> > no need to use build_standalone on most systems, including for cm3 itself (but it still works)<br>> ><br>> ><br>> ><br>> > - Jay<br>> <br>> -- <br>> Rodney Bates<br>> rodney.m.bates@acm.org<br></div> </div></div> </div></body>
</html>