<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'>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></body>
</html>