<div dir="ltr">Wolfgang - are you subscribed to the list? I can't see any of your original emails, just those quoted.<div><br></div><div>I've been thinking about this what seems to be missing is a "project" based approach. I emulate this by using include_dir instead of import and makefile overrides (for technical reasons), but right now makefiles don't let you nominate what libraries/packages are part of the active project and what are a part of another project. </div><div><br></div><div>When a large project, such as the compiler, involves several separate libraries/packages, you ought to be able to nominate them for rebuilding as required from the client package, instead of just importing whatever was last shipped. Instead we have the build scripts which are an unreliable and ugly hack. You may not want to have the compiler try to divine what should be rebuilt across arbitary packages, but you should be able to nominate what packages belong to the same project and have the compiler manage the builds.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 10, 2016 at 7:16 PM, Rodney M. Bates <span dir="ltr"><<a href="mailto:rodney_bates@lcwb.coop" target="_blank">rodney_bates@lcwb.coop</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
On 10/09/2016 03:22 PM, Rodney M. Bates wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
While there is plenty of room for improvement in CM3, perhaps it has<br>
provoked for you, a crisis of rising expectations, leading you to<br>
apply a higher standard than to other build systems.  The Modula-3<br>
language and the CM3 implementation of it are already far ahead of the<br>
prevailing standard for software build systems.<br>
<br>
For *within* a package, CM3 automatically detects and carries out any<br>
recompilation necessary due to changes, and on a declaration<br>
granularity.  If an interface you import has been changed only in<br>
declarations you do not actually reference, your code need not be<br>
recompiled.  Compare this to C/C++/Make, where, if the file you depend<br>
on has been touched in any way, even just editing of comments or just<br>
changing its recorded date, your file has to be recompiled.<br>
<br>
Moreover, the dependencies have to be manually written into a<br>
Makefile, or the recompilation will not occur when it is necessary.<br>
There are side tools around that will automatically generate Makefile<br>
dependencies, but they can only judge on the basis of #include lines,<br>
not actual uses.  They have to be rerun along with every<br>
recompilation, or else, inevitably, the Makefile will get out of date.<br>
That can lead to very difficult-to-diagnose bugs that often don't show<br>
up for a long time later, after many unrelated changes and rebuilds.<br>
<br>
Such tools cannot help with the very difficult task of discovering<br>
when a #include has become unnecessary.  This is extremely difficult<br>
to find, and requires combing through the entire closure of #includes,<br>
in order, not just the direct ones, looking for referenced<br>
declarations.  CM3, in contrast will warn of an IMPORT that is not<br>
needed.  BTW, in Modula-3,only the direct IMPORTs need to be examined.<br>
<br>
Between packages, CM3 always detects incompatibilities.  In most<br>
systems, the closest you get to this is via a package manager, e.g.,<br>
APT or RPM.  Again, for these to work, somebody has to manually note<br>
the dependencies in the package.  These are even coarser than<br>
file-granularity.  They can only use library names, with embedded<br>
version numbers, to detect problems.  There is nothing to check<br>
whether the version numbers correctly reflect incompatibilities.  What<br>
detection does happen is delayed from link time to install time.  And<br>
you have to manually rebuild the library to fix it.<br>
<br>
CM3 will always detect, at declaration granularity, at link time, when<br>
such an incompatibility exists, with no extra manual effort beyond the<br>
actual modification itself.  The worst you can criticize is that the<br>
messages are not very informative (but still much better), and as<br>
above, you have to ask for a recompile of your package.<br>
<br>
But the situation that brought this all up goes even deeper.  There,<br>
package cm3ide links in file ConnFD.i3, in package tcp, with object<br>
code in libm3tcp.so, which needs to be recompiled because it links in<br>
ThreadPThread.m3, in package m3core, compiled into libm3core.so.  This<br>
is (non-trivial) *transitive* dependency in the link closure of<br>
libraries.  CM3 detected this, but has to be asked manually to do the<br>
necessary recompilation.  I am far from knowledgeable about all build<br>
systems in existence, but I would be be very surprised if more than<br>
one or two others do even this detection.<br>
</blockquote>
<br></div></div>
Actually, I described this wrongly, or at oversimplifiedly.<br>
What I am sure really happed here is cm3ide links in m3core directly,<br>
and also links in tcp, which, the last time it was compiled,<br>
linked in a different (earlier, in this case, but not necessarily,<br>
in general) version of m3core, which is what CM3<br>
complained about.  It detected this directly from type<br>
definitions, without needing version numbers, file names,<br>
dates, etc.  It does however, rely on having the compiler-generated<br>
.M3WEB file for m3core properly installed beside the library.<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I am not even sure one would want a build system to automatically<br>
transitively rebuild across multiple libraries.  It might work<br>
when all the libraries are in a single repository like Modula3-cm3.<br>
But often, programs use libraries from very different projects,<br>
with source code in far-flung places, if available at all.<br>
<br>
I suppose one could write a Makefile that notes when a linked-in<br>
library depends on another linked-in library.  I doubt this has been<br>
done very often.  Even so, it would at best, detect only at whole<br>
library granularity.<br>
<br>
<br>
<br>
On 10/08/2016 01:22 AM, Wolfgang Keller wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The "upgrade" process claims to update a target installation system (perhaps also called the "work installation"). In my test case this was in " /home/user/Projekte/M3-Test2/"<wbr>. This is also the system which is made available in global environment paths.<br>
<br>
1) If - after creation of the target system - compiling "cm3" within "cm3ide" of CM3 (git) fails then the claim to having built a valid upgrade has also failed (if we assume that cm3ide holds a valid composition of sources).<br>
<br>
2) The compile process reports taking reference to m3bundle which appears to imply it is an essential part of the core compiler.<br>
<br>
"/home/user/Projekte/M3-Test2/<wbr>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>
3) If we look at the /bin directory of the target system, we find some updated executables with the exception of "cm3ide" and "m3bundle" which still date to 12 July 2010.<br>
<br>
4) Suspicion arises that omitting compilation or copy of m3bundle causes the failed compile process.<br>
<br>
5) Obviously the "cm3" folder in CM3 (git) is not a sufficient source for executing the compiler. Hence I recommend there should be a target "build" system inside the git working repository as a result of any "upgrade" or "build" script. This build area should be the primary target of all scripts targeting at ensuring a workable compiler installation. Then in a secondary step, which may also be scripted but may also be omitted, copy from this area can be taken to update, upgrade or build new any other installation. The "build" area in git can be set to .gitignore so it doesn't litter up the tracking system. Is that an idea to follow?<br>
<br>
- Wolfgang<br>
<br>
Am 08.10.2016 um 01:24 schrieb Rodney M. Bates:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On 10/07/2016 01:26 PM, Wolfgang Keller wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Am 07.10.2016 um 18:17 schrieb Rodney M. Bates:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On 10/07/2016 03:53 AM, Wolfgang Keller wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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/b<wbr>in/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>
</blockquote>
<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>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
</blockquote>
<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>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
</blockquote>
<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>
</blockquote>
<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/b<wbr>in/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>
</blockquote>
<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>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Theoretically, the missing file attributes may have had an impact on the results of the upgrade. Who knows?<br>
<br>
<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
-- <br>
Rodney Bates<br>
<a href="mailto:rodney.m.bates@acm.org" target="_blank">rodney.m.bates@acm.org</a><br>
______________________________<wbr>_________________<br>
M3devel mailing list<br>
<a href="mailto:M3devel@elegosoft.com" target="_blank">M3devel@elegosoft.com</a><br>
<a href="https://m3lists.elegosoft.com/mailman/listinfo/m3devel" rel="noreferrer" target="_blank">https://m3lists.elegosoft.com/<wbr>mailman/listinfo/m3devel</a><br>
</div></div></blockquote></div><br></div>