<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p></p>
<div> > I have worked in compilation systems for modular languages</div>
<div> > that have a two-level</div>
<div> > automatic rebuild system. Modula-3 does not. The automatic</div>
<div> > rebuild only works</div>
<div> > within a package. It would be nice to have one.</div>
<div><br>
</div>
<div>We have another opportunity -- rebuild everything, but incrementally.</div>
<div><br>
</div>
<div> do-cm3-all buildship</div>
<div><br>
</div>
<div>or such. Already there. But there are some incrementality bugs</div>
<div> in cm3. I know, for example, moving a module/interface between</div>
<div> packages doesn't work.</div>
<div><br>
</div>
<div><br>
</div>
<div>I think do-cm3-all-kinda should be easy to work into cm3 itself.</div>
<div>It just needs to know where all the packages are.</div>
<div>I believe package boundaries are already declared, via program(), library(),</div>
<div>etc. occuring last in m3makefiles per package.</div>
<div><br>
</div>
<div><br>
</div>
<div> > The independent installation should stay unmodified</div>
<div> > in its functionality. Users might wish to continue to use it,</div>
<div> > e.g. when the newer version proves buggy or otherwise undesirable.</div>
<div><br>
</div>
<div><br>
</div>
<div> We all mostly agree but haven't been able to change it. </div>
<div><br>
</div>
<div> Some of the build automation (make-dist.py) actually first </div>
<div> copies the existing install, then builds and updates it in place.</div>
<div><br>
</div>
<div> You might try it.</div>
<div><br>
</div>
<div><br>
</div>
<div> - Jay</div>
<br>
<p></p>
<p><br>
</p>
<div id="Signature"><br>
</div>
<br>
<br>
<div style="color: rgb(0, 0, 0);">
<div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> M3devel <m3devel-bounces@elegosoft.com> on behalf of Rodney M. Bates <rodney_bates@lcwb.coop><br>
<b>Sent:</b> Friday, October 7, 2016 11:24 PM<br>
<b>To:</b> Wolfgang Keller; rodney.m.bates@acm.org; m3devel<br>
<b>Subject:</b> Re: [M3devel] CM3 report compiler compilation</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
<br>
On 10/07/2016 01:26 PM, Wolfgang Keller wrote:<br>
><br>
><br>
> Am 07.10.2016 um 18:17 schrieb Rodney M. Bates:<br>
>><br>
>><br>
>> On 10/07/2016 03:53 AM, Wolfgang Keller wrote:<br>
>>> I attempted at compiler compilation and found a few peculiar things.<br>
>>><br>
>>> 1. The Result<br>
>>><br>
>>> Critical Mass Modula-3 version d5.10.0<br>
>>> last updated: 2015-05-21<br>
>>> compiled: 2016-10-07 03:58:31<br>
>>> configuration: /home/user/Projekte/M3-Test2/bin/cm3.cfg<br>
>>> host: AMD64_LINUX<br>
>>> target: AMD64_LINUX<br>
>>><br>
>>> This is how cm3 identifies.<br>
>>><br>
>>> a) "last updated" - since you modified the sources, should there be a younger date?<br>
>><br>
>> Yes. This is now manually updated in scripts/version.quake.<br>
>><br>
>> m3devel list: We need to do this with every commit, or else automate it.<br>
>><br>
>>><br>
>>> b) compilation results (executables) as well as configuration file have been put into CM3 (Git version) folders and into the "independent" installation of the older version of CM3, i.e. 5.8.6. I see this critical! The independent installation should stay
unmodified in its functionality. Users might wish to continue to use it, e.g. when the newer version proves buggy or otherwise undesirable.<br>
>>><br>
>><br>
>> Yes, we have been working on this. You can recreate a clean release installation at<br>
>> any time, but it's a real pain for intermediate versions during development. I am<br>
>> very conservative about saving existing versions before touching the compiler or its<br>
>> core libraries, either by copying critical executable file and library files, or making<br>
>> whole copies of /usr/local/cm3.<br>
>><br>
>>> c) Erroneous execution. When calling "cm3" in the "cm3ide" directory it does not compile and the text result is<br>
>>><br>
>>> -- begin --<br>
>>> --- building in AMD64_LINUX ---<br>
>>><br>
>>> ignoring ../src/m3overrides<br>
>>><br>
>>> Fatal Error: bad version stamps: ConnFD.i3<br>
>>><br>
>>> inconsistent opaque object info for type _t1541f475<br>
>>> super type: _te422a136 data: (size: 64, align: 64) method: (size: 0)<br>
>>> => ConnFD.i3<br>
>>> super type: _te422a136 data: (size: 192, align: 64) method: (size: 0)<br>
>>> => ThreadPThread.m3<br>
>>><br>
>>> -- end --<br>
>>><br>
>><br>
>> This is almost certainly a need for complete recompile of cm3ide. Try, in<br>
>> the cm3ide directory:<br>
>><br>
>> cm3 -realclean<br>
>> cm3<br>
>><br>
>><br>
>> Within a package, the compiler infers from source code what needs to be recompiled<br>
>> and does so. Between packages, and for certain kinds of changes in machine-level<br>
>> types, it can only detect incompatibilities. This is rare. The messages are<br>
>> highly uninformative, but fixing them requires changes to the compiler's internal<br>
>> intermediate representation, which entails widespread, but mundane code changes.<br>
>> I have undertaken some of this previously, but it hasn't had the highest priority.<br>
><br>
> Taking your advice it results in the following:<br>
><br>
> -- begin --<br>
> --- building in AMD64_LINUX ---<br>
><br>
> ignoring ../src/m3overrides<br>
><br>
> /home/user/Projekte/M3-Test2/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk<br>
> new source -> compiling Buf.i3<br>
> new source -> compiling Buf.m3<br>
> new source -> compiling ErrLog.i3<br>
> new source -> compiling ErrLog.m3<br>
><br>
> Fatal Error: bad version stamps: ConnFD.i3<br>
><br>
> inconsistent opaque object info for type _t1541f475<br>
> super type: _te422a136 data: (size: 64, align: 64) method: (size: 0)<br>
> => ConnFD.i3<br>
> super type: _te422a136 data: (size: 192, align: 64) method: (size: 0)<br>
> => ThreadPThread.m3<br>
> -- end --<br>
><br>
> Obviously compilation takes reference into the "other" installation and resulting in inconsistencies. Why does it do so? This is the type of mixed up configurations that I have been speaking of! Up to now I don't quite understand how people are working with
this system. Does it work for you?<br>
><br>
<br>
It's the other way around. ConnFD.i3 has an old, already compiled version around that<br>
depends on something in ThreadPThread, which has changed and been recently recompiled.<br>
ConnFD.i3 now needs to be recompiled to adapt, now that a new libm3core is installed<br>
(which ThreadPThread is part of).<br>
<br>
I should have looked at where ConnFD.i3 is located. It's in package group m3-comm, which<br>
upgrade.sh apparently didn't rebuild. So try this, as I just did:<br>
<br>
in directory scripts:<br>
<br>
./do-cm3-comm.sh realclean<br>
,/do-cm3-comm.sh buildship<br>
<br>
Then try rebuilding cm3ide. There could be more things that haven't been rebuilt<br>
by update.sh. I would predict that m3-ui and m3-db haven't, though I doubt cm3ide<br>
needs m3-ui. There are do-cm3-*.sh scripts for a lot of these groups.<br>
<br>
I have worked in compilation systems for modular languages that have a two-level<br>
automatic rebuild system. Modula-3 does not. The automatic rebuild only works<br>
within a package. It would be nice to have one.<br>
<br>
> Theoretically, the missing file attributes may have had an impact on the results of the upgrade. Who knows?<br>
><br>
><br>
><br>
><br>
<br>
-- <br>
Rodney Bates<br>
rodney.m.bates@acm.org<br>
_______________________________________________<br>
M3devel mailing list<br>
M3devel@elegosoft.com<br>
<a href="https://m3lists.elegosoft.com/mailman/listinfo/m3devel" id="LPlnk375349" previewremoved="true">https://m3lists.elegosoft.com/mailman/listinfo/m3devel</a><br>
</div>
</span></font></div>
</div>
</body>
</html>