<HTML><HEAD>
<STYLE><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></STYLE>
</HEAD>
<BODY class=hmmessage dir=ltr>
<DIV dir=ltr>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: 'Arial'; COLOR: #000000">
<DIV>Has anybody ever considered to use <A href="http://0install.net/">Zero
Install</A> for shipping and distribution?</DIV>
<DIV
style='FONT-SIZE: small; TEXT-DECORATION: none; FONT-FAMILY: "Calibri"; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; DISPLAY: inline'>
<DIV style="FONT: 10pt tahoma">
<DIV><FONT size=3 face=Arial></FONT> </DIV>
<DIV style="BACKGROUND: #f5f5f5">
<DIV style="font-color: black"><B>From:</B> <A title=jay.krell@cornell.edu
href="mailto:jay.krell@cornell.edu">Jay K</A> </DIV>
<DIV><B>Sent:</B> Tuesday, March 24, 2015 9:29 AM</DIV>
<DIV><B>To:</B> <A title=rodney.m.bates@acm.org
href="mailto:rodney.m.bates@acm.org">rodney.m.bates@acm.org</A> ; <A
title=m3devel@elegosoft.com href="mailto:m3devel@elegosoft.com">m3devel</A>
</DIV>
<DIV><B>Subject:</B> Re: [M3devel] propose "output root" to replace
shipping</DIV></DIV></DIV>
<DIV> </DIV></DIV>
<DIV
style='FONT-SIZE: small; TEXT-DECORATION: none; FONT-FAMILY: "Calibri"; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; DISPLAY: inline'>
<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></DIV></DIV></DIV></BODY></HTML>