[M3devel] CM3 report compiler compilation

[Jay K]

 > I have worked in compilation systems for modular languages
 > that have a two-level
 > automatic rebuild system.  Modula-3 does not.  The automatic
 > rebuild only works
 > within a package.  It would be nice to have one.

We have another opportunity -- rebuild everything, but incrementally.

 do-cm3-all buildship

or such. Already there. But there are some incrementality bugs
 in cm3. I know, for example, moving a module/interface between
 packages doesn't work.


I think do-cm3-all-kinda should be easy to work into cm3 itself.
It just needs to know where all the packages are.
I believe package boundaries are already declared, via program(), library(),
etc. occuring last in m3makefiles per package.


 > 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.


 We all mostly agree but haven't been able to change it.

 Some of the build automation (make-dist.py) actually first
 copies the existing install, then builds and updates it in place.

 You might try it.


 - Jay





________________________________
From: M3devel <m3devel-bounces at elegosoft.com> on behalf of Rodney M. Bates <rodney_bates at lcwb.coop>
Sent: Friday, October 7, 2016 11:24 PM
To: Wolfgang Keller; rodney.m.bates at acm.org; m3devel
Subject: Re: [M3devel] CM3 report compiler compilation



On 10/07/2016 01:26 PM, Wolfgang Keller wrote:
>
>
> Am 07.10.2016 um 18:17 schrieb Rodney M. Bates:
>>
>>
>> On 10/07/2016 03:53 AM, Wolfgang Keller wrote:
>>> I attempted at compiler compilation and found a few peculiar things.
>>>
>>> 1. The Result
>>>
>>> Critical Mass Modula-3 version d5.10.0
>>>    last updated: 2015-05-21
>>>    compiled: 2016-10-07 03:58:31
>>>    configuration: /home/user/Projekte/M3-Test2/bin/cm3.cfg
>>>    host: AMD64_LINUX
>>>    target: AMD64_LINUX
>>>
>>> This is how cm3 identifies.
>>>
>>> a) "last updated" - since you modified the sources, should there be a younger date?
>>
>> Yes.  This is now manually updated in scripts/version.quake.
>>
>> m3devel list:  We need to do this with every commit, or else automate it.
>>
>>>
>>> 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.
>>>
>>
>> Yes, we have been working on this.  You can recreate a clean release installation at
>> any time, but it's a real pain for intermediate versions during development.  I am
>> very conservative about saving existing versions before touching the compiler or its
>> core libraries, either by copying critical executable file and library files, or making
>> whole copies of /usr/local/cm3.
>>
>>> c) Erroneous execution. When calling "cm3" in the "cm3ide" directory it does not compile and the text result is
>>>
>>> -- begin --
>>> --- building in AMD64_LINUX ---
>>>
>>> ignoring ../src/m3overrides
>>>
>>> Fatal Error: bad version stamps: ConnFD.i3
>>>
>>> inconsistent opaque object info for type _t1541f475
>>> super type: _te422a136  data: (size: 64, align: 64)  method: (size: 0)
>>>   => ConnFD.i3
>>> super type: _te422a136  data: (size: 192, align: 64)  method: (size: 0)
>>>   => ThreadPThread.m3
>>>
>>> -- end --
>>>
>>
>> This is almost certainly a need for complete recompile of cm3ide. Try, in
>> the cm3ide directory:
>>
>> cm3 -realclean
>> cm3
>>
>>
>> Within a package, the compiler infers from source code what needs to be recompiled
>> and does so. Between packages, and for certain kinds of changes in machine-level
>> types, it can only detect incompatibilities.  This is rare.  The messages are
>> highly uninformative, but fixing them requires changes to the compiler's internal
>> intermediate representation, which entails widespread, but mundane code changes.
>> I have undertaken some of this previously, but it hasn't had the highest priority.
>
> Taking your advice it results in the following:
>
> -- begin --
> --- building in AMD64_LINUX ---
>
> ignoring ../src/m3overrides
>
> /home/user/Projekte/M3-Test2/bin/m3bundle -name CM3_IDE_Bundle -F/tmp/qk
> new source -> compiling Buf.i3
> new source -> compiling Buf.m3
> new source -> compiling ErrLog.i3
> new source -> compiling ErrLog.m3
>
> Fatal Error: bad version stamps: ConnFD.i3
>
> inconsistent opaque object info for type _t1541f475
> super type: _te422a136  data: (size: 64, align: 64)  method: (size: 0)
>   => ConnFD.i3
> super type: _te422a136  data: (size: 192, align: 64)  method: (size: 0)
>   => ThreadPThread.m3
> -- end --
>
> 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?
>

It's the other way around.  ConnFD.i3 has an old, already compiled version around that
depends on something in ThreadPThread, which has changed and been recently recompiled.
ConnFD.i3 now needs to be recompiled to adapt, now that a new libm3core is installed
(which ThreadPThread is part of).

I should have looked at where ConnFD.i3 is located.  It's in package group m3-comm, which
upgrade.sh apparently didn't rebuild.  So try this, as I just did:

in directory scripts:

./do-cm3-comm.sh realclean
,/do-cm3-comm.sh buildship

Then try rebuilding cm3ide.  There could be more things that haven't been rebuilt
by update.sh.  I would predict that m3-ui and m3-db haven't, though I doubt cm3ide
needs m3-ui.  There are do-cm3-*.sh scripts for a lot of these groups.

I have worked in compilation systems for modular languages that have a two-level
automatic rebuild system.  Modula-3 does not.  The automatic rebuild only works
within a package.  It would be nice to have one.

> Theoretically, the missing file attributes may have had an impact on the results of the upgrade. Who knows?
>
>
>
>

--
Rodney Bates
rodney.m.bates at acm.org
_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://m3lists.elegosoft.com/mailman/listinfo/m3devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20161008/39d5ccb3/attachment-0001.html>