<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'>> if equal($INSTALL_CM3_IN_BIN, "yes")<br><BR> <BR>Hm. That is relatively new.<br>Rodney, This is a mistake:<br> <a href="https://github.com/modula3/cm3/commit/1994f950bb30c3021fd24c07a555f0f7bace933f">https://github.com/modula3/cm3/commit/1994f950bb30c3021fd24c07a555f0f7bace933f</a><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><div>> 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></div> </div></body>
</html>