<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'>I believe the variable existed for cm3, but not m3cc/cm3cg. Rodney added it for m3cc/cm3cg.<BR> <BR> - Jay<br><br> <BR><div>> Date: Fri, 29 May 2015 14:04:02 +0200<br>> From: wagner@elego.de<br>> To: jay.krell@cornell.edu<br>> CC: m3devel@elegosoft.com; rodney.m.bates@acm.org<br>> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110<br>> <br>> On Fri, 29 May 2015 11:45:02 +0000<br>> Jay K <jay.krell@cornell.edu> wrote:<br>> <br>> > The workaround is bad, as it affects m3-sys/cm3 also.<br>> > Rodney, this really should be removed. If you must have something like this, make it a separate variable from cm3. Please.<br>> <br>> I don't think Rodney introduced this variable ;-)<br>> <br>> Olaf<br>> <br>> > - Jay<br>> > <br>> > <br>> > <br>> > From: jay.krell@cornell.edu<br>> > To: wagner@elegosoft.com<br>> > Date: Fri, 29 May 2015 11:22:15 +0000<br>> > CC: m3devel@elegosoft.com; rodney.m.bates@acm.org<br>> > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110<br>> > <br>> > <br>> > <br>> > <br>> > > if equal($INSTALL_CM3_IN_BIN, "yes")<br>> > <br>> > <br>> > Hm. That is relatively new.<br>> > Rodney, This is a mistake:<br>> > https://github.com/modula3/cm3/commit/1994f950bb30c3021fd24c07a555f0f7bace933f<br>> > <br>> > <br>> > I see you commented it heavily, but we had working automation before that this broke.<br>> > The automation already took into account what you were trying to take into account.<br>> > <br>> > <br>> > I agree having the config search all over, which I did, is not good,<br>> > as it undermines attempts to ship at just the right time.<br>> > <br>> > <br>> > If you don't want to ship cm3cg, then don't run cm3 -ship for it.<br>> > cm3cg is not actually running when cm3 -ship is run.<br>> > The reasons cm3 doesn't ship itself do not apply.<br>> > <br>> > <br>> > I agree it seems tempting to sync this behavior with the behavior of shipping cm3.<br>> > But I don't think it should be.<br>> > <br>> > <br>> > Yes the files have to be updated together. <br>> > You do that by shipping cm3cg and somehow otherwise copying cm3. <br>> > I agree that having this "somehow otherwise copy" is not great.<br>> > I wonder if we can remove that though. <br>> > <br>> > <br>> > The reason cm3 ship is disabled by default is not so that things are updated together,<br>> > but because having an executable copy over itself reportedly does not work on some operating systems. <br>> > It is nothing to do with our need to copy multiple files automatically. It is because it will fail. <br>> > <br>> > <br>> > <br>> > Now..I must say..Windows is extremely often labeled as one of these systems. <br>> > Countless people believe this myth. But it isn't true. <br>> > You can copy over an "in use" .dll or .exe. <br>> > You merely have to rename it away first. Yes, that is still a bit wierd.<br>> > And I have to investigate how to eventually delete it.<br>> > Yes, there is a way to defer the delete..until a reboot..if you are an administrator..<br>> > but that is clearly an inadequate mechanism. It is quite possible you open with delete_on_close, <br>> > and close, and then the last close might do it, when the .exe stops running.<br>> > We should try this out.<br>> > <br>> > <br>> > <br>> > However, with Windows possibly eliminated as a concern (once ship does the rename, which it doesn't currently),<br>> > does that leave other systems? AIX I believe is similar..that a direct copy will fail.<br>> > But will rename work around it there too?<br>> > <br>> > <br>> > Should we let cm3 be able to ship itself, and see what comes of it? <br>> > Like, maybe every system people really use can do it? <br>> > When an AIX user speaks up, we can fix it then??<br>> > <br>> > <br>> > <br>> > Either way, I believe this change to m3cc/src/m3makefile should be undone.<br>> > <br>> > <br>> > In the meantime, everyone can workaround it by setting the environment variable.<br>> > <br>> > <br>> > The other angle, which I've been pushing unsuccessfully is never update in place.<br>> > That is portable. <br>> > Start with a new empty directory tree and fill it in by shipping, even cm3.<br>> > Like make-dist.py does.<br>> > One wrinkle here is that cm3, if it doesn't already, must favor looking next to itself, and not searching $PATH.<br>> > So that you ship cm3cg to the new place, and then cm3, and cm3 shipping second finishes the transaction (ok,<br>> > you'd also copy/ship other files, like configs and m3core/libm3, and then cm3 last).<br>> > <br>> > <br>> > <br>> > I would really really like that code for an executable to find its full path, on all supported systems.<br>> > I don't think Posix can do it. Win32 GetModuleFileName(NULL or &__ImageBase) for example.<br>> > Then strip off the last path element and append stuff, to find things you go with.<br>> > It is a nice technique.<br>> > I'm leary of techniques that rely on $PATH search or applying argv[0] to getcwd, as the current directory can change at any time.<br>> > <br>> > <br>> > (and another unsuccessful angle is to move away from all the .sh files; I've been using the .py files for years...well, I was...)<br>> > <br>> > <br>> > <br>> > - Jay<br>> > <br>> > <br>> > <br>> > > Date: Thu, 28 May 2015 23:05:54 +0200<br>> > > From: wagner@elegosoft.com<br>> > > To: jay.krell@cornell.edu<br>> > > CC: rodney.m.bates@acm.org; m3devel@elegosoft.com; adacore@marino.st<br>> > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110<br>> > > <br>> > > On Thu, 28 May 2015 20:14:49 +0000<br>> > > Jay K <jay.krell@cornell.edu> wrote:<br>> > > <br>> > > > > Also, this script built the compiler before the support libraries m3core and<br>> > > > > libm3. I think there may have been one bootstrap scenario where this was the<br>> > > > > way it needed to be done, but usually it is the other way around--these two<br>> > > > > libraries first.<br>> > > > <br>> > > > This is very deliberate and should always work, when doing a native upgrade. <br>> > > > It is true it is not always required. <br>> > > > When doing a "clean" cross build, it is true that it is backwards. <br>> > > > It is required when upgrading from an older build. <br>> > > > <br>> > > > Native upgrades start at least with a working compiler and its matching runtime.<br>> > > > Cross builds start with a working host compiler and nothing for the target -- so they do start with m3core.<br>> > > <br>> > > I've had a look at the build log, and I think the problem in this case<br>> > > with upgrade.py might be that it doesn't install the new backend, but<br>> > > only the new frontend:<br>> > > <br>> > > [...]<br>> > > Not shipping cm3cg.<br>> > > --- shipping from AMD64_FREEBSD ---<br>> > > <br>> > > missing ".M3SHIP" file, build the package first.<br>> > > dula3/work/bootstrap/bin/cm3 -build -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++<br>> > > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done<br>> > > <br>> > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++<br>> > > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done<br>> > > <br>> > > mkdir -p /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin<br>> > > cp -Pv /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/cm3/AMD64_FREEBSD/cm3 /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin/cm3<br>> > > [...]<br>> > > <br>> > > In the upgrade.sh script I used install-cm3-compiler.sh, which always<br>> > > installs both. In m3-sys/m3cc/src/m3makefile I find the following code:<br>> > > <br>> > > if equal($INSTALL_CM3_IN_BIN, "yes")<br>> > > deriveds("", ["cm3cg", "cm3cg.exe"])<br>> > > write ( "Forced ship of cm3cg." & CR) <br>> > > BindExport (AppendExeExtension ("cm3cg"))<br>> > > if DoMipsTfile<br>> > > BindExport ("mips-tfile")<br>> > > end<br>> > > else <br>> > > write ( "Not shipping cm3cg." & CR) <br>> > > end <br>> > > <br>> > > So perhaps simply setting INSTALL_CM3_IN_BIN=yes in the environment<br>> > > will fix that problem?<br>> > > <br>> > > Olaf<br>> > > -- <br>> > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com <br>> > > Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<br>> > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<br>> > > Geschäftsführer: Olaf Wagner | Sitz: Berlin<br>> > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<br>> > <br>> <br>> -- <br>> Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com <br>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<br>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<br>> Geschäftsführer: Olaf Wagner | Sitz: Berlin<br>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<br></div> </div></body>
</html>