[M3devel] CM3 report compiler compilation

[Rodney M. Bates]

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