<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'>Sorry I'm rushing here..:<BR> <BR> <BR>Imho, build should build and ship should ship and buildship should do both.<BR>If that isn't the case, we should fix.<BR>Then, if you don't want to ship something, don't ship it.<BR>Not, ship it and set the environment variable.<BR> <BR> <BR> <BR> >implied: What is override?<BR> <BR> <BR>There are essentially two package pools, or sets of libraries, to chose from.<BR> <BR><br>They are roughly speaking the installed/shipped stuff:<BR> /usr/local/cm3/pkg/m3core/target (obviously it can vary) <BR><br>and the locally built but not yet shipped stuff, I call them:<BR><br> $HOME/dev2/cm3/m3-libs/m3core/target (obviously it can vary)<BR> <BR><br>I also call this "the object tree", i.e. the tree with a bunch of .obj/.o files.<br>Or the "intermediates" tree, i.e. a bunch of outputs that are pruned out by "setup",<br>and the outputs that are ultimately interesting <BR><br> <BR> The default is the first, override means to use the second. <BR> <BR><br> Then, the idea is that only stuff built against the install is safe <br> to overwrite/add to the install. <BR><br> <BR> But I think is missing there is that, well, if I've built the entire<br> system with overrides and I'm going to ship the entire system, then ship is safe. <BR> <BR> <BR>This isn't the best approach imho.<BR> Arguably better approaches are: <br> always have a 2-level search <br> first the object tree <br> then the install tree <BR> <BR><br> This breaks people who switch around between<br> incompatible changes in m3core and random application development,<br> with the same source/object tree. However maybe that is just tough.<BR><br> <BR> The object tree doesn't have to be in the source tree.<br><BR> <BR> You should be able to say, like:<br> symlinktree /usr/local/cm3 /working-on-feature1<br> export/set CM3_SOMETHING=/working-on-feature1 and <br> case I change cm3 also export/set PATH=/working-on-feature1/bin:$PATH <br> and then copy on write as you ship<BR><br> <BR> and then to switch to some other work:<BR> <BR> symlinktree /usr/local/cm3 /working-on-feature2<br> export/set CM3_SOMETHING=/working-on-feature2 and<br> case I change cm3 also export/set PATH=/working-on-feature2/bin:$PATH<br> and then copy on write as you ship, different stuff<BR> <BR> <br> That is a working model that I advocate but don't yet follow. Though make-dist kind of does. <BR> make-dist copies the compiler to the new location and then does buildship.<BR> In this model, you don't have overrides and you always build/ship.<br> And if you mess up, you can start over easily.<BR> <BR><br> But I haven't actually established workflow here so I'm just talking too much. :<BR> A real analog in other people's workflows is:<br> mkdir /obj/working-on-feature1<br> cd /obj/working-on-feature1 <br> /src/configure ...<br> make<BR> mkdir /obj/working-on-feature2 <br> cd /obj/working-on-feature2 <br> /src/configure ...potentially different ..<br> make<BR> <BR><br> .sh build should not ship. Agreed. <br> Currently if you are going to ship, you can't override.<BR> <BR><br> make-dist.py uses a destdir-like approach. <BR> <BR><br> There is some contention perhaps of scenarios of "I'm just building a little,<br> small safe changes" and "I'm rebuilding everything, and possibly messing up".<BR><br> <BR> I really want the environment variable checks to go away.<BR> <BR><br> - Jay<br><br><br><br> <BR><div>> Date: Mon, 1 Jun 2015 12:48:34 -0500<br>> From: rodney_bates@lcwb.coop<br>> To: jay.krell@cornell.edu; m3devel@elegosoft.com<br>> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110<br>> <br>> <br>> <br>> On 06/01/2015 01:40 AM, Jay K wrote:<br>> > Yes, exactly, that's what I was trying to say, in my later/last mail.<br>> ><br>> ><br>> > Yes the compability is definitely two-way.<br>> > There is a one to one mapping back and forth.<br>> > cm3 goes with cm3cg; cm3cg goes with cm3.<br>> > Neither is compatible with older nor necessarily newer versions.<br>> ><br>> ><br>> > They would be statically linked together if not for the GPL.<br>> ><br>> ><br>> > When I first placed m3cc in pkginfo.txt years ago, I was only thinking<br>> > of build order and, like, "override".<br>> ><br>> ><br>> > m3cc imports nothing and nothing imports m3cc.<br>> > In the Modula-3 module/library/interface sense.<br>> ><br>> ><br>> > It can be built when you have nothing.<br>> > So I figured put it nearly first.<br>> ><br>> ><br>> > Only now today did I consider the shipping order.<br>> > It should be shipped adjacent to cm3, either right before or right after.<br>> ><br>> ><br>> > If you split build and ship, then it can still be built early,<br>> > or at almost any time.<br>> ><br>> <br>> Yes, this is the way I want to do building. First build everything you want to<br>> without putting any of it into use as build tools. Then put it all into use.<br>> <br>> One annoyance we currently have is that the do-cm3.*.sh scripts have, perhaps<br>> we should call them subcommands, like realclean, build, ship, buildship, etc.<br>> But the cm3 command treats their counterparts as command line options,<br>> -realclean, -build, -ship, -buildship, etc. I would like to consistify<br>> this. Removing the hyphen from cm3 would create ambiguities with file names,<br>> so it would mean adding the hyphen to the scripts.<br>> <br>> Much more serious is that similarly-named options do not have the same meaning<br>> in the scripts and in cm3. cm3 -build followed by cm3 -ship works as I expect,<br>> but do-cm3-*.sh build causes me nothing but trouble, and I learned long ago to<br>> avoid it. Instead, I always use do-cm3-*.sh buildship. This ships almost everything<br>> as it is built, but usually only cm3 and cm3cg executables matter, and today, they are<br>> specifically excepted from shipping, if you do not set INSTALL_CM3_IN_BIN="yes".<br>> <br>> I am writing from memory, but I think the problem with do-cm3-*.sh build is that<br>> build also uses overrides, which I barely understand, except that they, at best<br>> make things unshippable, and I think there was some other problem too. If we<br>> made the override thing a separate option to the scripts, so just build would<br>> neither ship nor override, I think that would satisfy my need, at least for the<br>> time being. And it would be consistent.<br>> <br>> Actually, I think we do want to use just-rebuilt packages when linking to them.<br>> Only executables and things they link in (possibly dynamically) need to be<br>> left alone until a later ship step. This usually only means cm3, cm3cg,<br>> and, if dynamically linked in, m3core. But there are others to think about,<br>> e.g., m3bundle, stubgen, netobjgen.<br>> <br>> ><br>> > But we have one ordering for build and ship, so let the shipping order decide.<br>> ><br>> ><br>> > I still don't like INSTALL_CM3_IN_BIN and I'd still like to remove it.<br>> <br>> I have no objection to addressing the copy-over-an-executing-executable problem<br>> in a different way, and no objection to getting rid of the environment variable.<br>> But I do want it, for now at least, to be possible to get it to not ship either<br>> cm3 or cm3cg, even with the buildship option. If it just unconditionally doesn't<br>> ship them, that is fine. Before I added the variable check for the cm3cg package,<br>> it was unconditionally shipping it.<br>> <br>> > I still think it broke upgrade.py.<br>> > I can workaround. But I'd like to remove the environment variable check.<br>> ><br>> ><br>> > There are many order dependencies in build and ship. This is just one.<br>> ><br>> ><br>> > - Jay<br>> ><br>> ><br>> ><br>> ><br>> > > Date: Sun, 31 May 2015 22:28:13 -0500<br>> > > From: rodney_bates@lcwb.coop<br>> > > To: m3devel@elegosoft.com; adacore@marino.st<br>> > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110<br>> > ><br>> > > I am quite sure that the cm3/cm3cg incompatibility is two-way, i.e.,<br>> > > both must be new or both old. So, I would expect INSTALL_CM3_IN_BIN=yes<br>> > > to fail regardless of the order of building the two.<br>> > ><br>> > > OTOH, if cm3 were built and shipped, then m3cc came immediately after,<br>> > > it should work, because m3cc contains no Modula-3 code, and the new<br>> > > cm3 would not, when building it, run cm3cg. After that, there would<br>> > > be a consistent set. for further compiles. But any package containing<br>> > > M3 code built between cm3 and m3cc would fail.<br>> > ><br>> > > On 05/31/2015 05:15 PM, Jay wrote:<br>> > > > I think now it might not be the problem. Could be m3cc needs to be later in pkginfo.txt. I have to try later.<br>> > > ><br>> > > > - Jay<br>> > > ><br>> > > > On May 31, 2015, at 10:59 AM, John Marino <adacore@marino.st> wrote:<br>> > > ><br>> > > >> I removed "INSTALL_CM3_IN_BIN=yes" after reading the thread about it.<br>> > > >> Should I put it back? From the last response I'm guessing that wasn't<br>> > > >> the problem.<br>> > > >><br>> > > >> John<br>> > > >><br>> > > >><br>> > > >> On 5/31/2015 19:09, Jay K wrote:<br>> > > >>> Oh probably the problem is using the backend premature actually.<br>> > > >>> Darn, I can't help right now.<br>> > > >>><br>> > > >>> - Jay<br>> > > >>><br>> > > >>><br>> > > >>><br>> > > >>> ------------------------------------------------------------------------<br>> > > >>> From: jay.krell@cornell.edu<br>> > > >>> To: adacore@marino.st; m3devel@elegosoft.com<br>> > > >>> Date: Sun, 31 May 2015 16:45:42 +0000<br>> > > >>> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp<br>> > > >>> (0x100), expected 0x110<br>> > > >>><br>> > > >>> Hm. Strange. I need to read more closely. I see it skipping shipping,<br>> > > >>> but my read was it didn't try that.<br>> > > >>> So.. with INSTALL_CM3_IN_BIN=yes?<br>> > > >>> I need to try this all, and "fix" it to set that. The whole thing in<br>> > > >>> m3cc/src/m3makefile is relatively<br>> > > >>> new vs. when I was actively using all this. :(<br>> > > >>><br>> > > >>> - Jay<br>> > > >>><br>> > > >>><br>> > > >>>> Date: Sun, 31 May 2015 16:57:02 +0200<br>> > > >>>> From: adacore@marino.st<br>> > > >>>> To: jay.krell@cornell.edu; m3devel@elegosoft.com<br>> > > >>>> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp<br>> > > >>> (0x100), expected 0x110<br>> > > >>>><br>> > > >>>> On 5/31/2015 11:53, Jay K wrote:<br>> > > >>>>> John, have you tried make-dist.py?<br>> > > >>>>> i.e.<br>> > > >>> https://github.com/modula3/cm3/blob/master/scripts/python/make-dist.py<br>> > > >>>>><br>> > > >>>>> While it might not be exactly what you need, it should demonstrate the<br>> > > >>>>> elements.<br>> > > >>>>><br>> > > >>>>> I will try to try this all soon, really, I hope so.<br>> > > >>>>><br>> > > >>>>> It starts with a working compiler, does no in-place updates, build into<br>> > > >>>>> a unique directory in /tmp, and gives you .tar.gz or such at the end.<br>> > > >>>>> It does "min" and "all".<br>> > > >>>>><br>> > > >>>>> If you set the STAGE environment variable, it uses that instead of /tmp.<br>> > > >>>>> It should probably be called M3_STATE or M3_MAKEDIST_STAGE.<br>> > > >>>>><br>> > > >>>>> - Jay<br>> > > >>>><br>> > > >>>> Hi Jay,<br>> > > >>>> I'm getting the same error as always using make-dist script:<br>> > > >>>> http://leaf.dragonflybsd.org/~marino/m3d.log<br>> > > >>>><br>> > > >>>> Thanks,<br>> > > >>>> John<br>> > > ><br>> > ><br>> > > --<br>> > > Rodney Bates<br>> > > rodney.m.bates@acm.org<br>> <br>> -- <br>> Rodney Bates<br>> rodney.m.bates@acm.org<br></div> </div></body>
</html>