<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'>It only happens if you ship.<BR>Shipping in the wrong order can always break things.<BR>You cannot ship in arbitrary order and incorrect order can cause arbitrary problems.<BR>That doesn't mean we should never ship and always have a separate copy mechanism.<BR>The knowledge of what to ship is meant to be in the m3makefiles. Not also<BR>encoded elsewhere.<BR> <BR> <BR>The environment variable check really should be removed.<BR> <BR>Perhaps perhaps perh<BR>aps shipping order can be enforced?<BR>For things other than m3cc, this seems possible.<BR>Immediate matching dependencies should be present in the destination.<BR>Using the information that is already present in the system as to immediate<BR>and matching, in terms of Modula-3 imports/interfaces.<BR> <BR> <BR>m3cc is unique in not fitting in that however.<BR>As well, the dependency between m3cc/cm3 -- what order would you say it is?<BR>Circular but the tie can be broken arbitrarily?<BR> <BR> <BR>Introduce a command that can ship multiple packages at once?<BR>I kind of want that anyway, but in this case you'd arrive back at the environment variable,<BR>as long as cm3 has it..though cm3 only needs it for NT and hypothetical other targets<BR>like AIX/OS2/DOS/DJGPP.<BR> <BR>However -- how about this suggestion -- make the environment variable check for relative native target?<BR> <BR>Only skip cm3 shipping when we know it doesn't work, I..e NT/Cygwin/Mingwin?<BR>I like this. It is a special case either way, but at least we can demonstrate a cleaner system on most systems..<BR> <BR> <BR> <BR> - Jay<br><br><br> <BR><div>> Date: Sun, 31 May 2015 13:30:46 -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>> <br>> <br>> On 05/31/2015 12:59 PM, John Marino wrote:<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>> It apparently wasn't the only problem, but it definitely was a problem.<br>> Don't put it back. I causes the new cm3cg executable to be copied<br>> to your bin directory immediately after it has been built. It is<br>> incompatible with the old cm3 executable, and the next attempted<br>> build (m3core, as I remember) runs the old cm3, then the new cm3cg,<br>> which correctly recognizes that its input is in an old version format<br>> and refuses, giving the error message.<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>> >>><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></div> </div></body>
</html>