<HTML><HEAD></HEAD>
<BODY dir=ltr>
<DIV dir=ltr>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: 'Arial'; COLOR: #000000">
<DIV><A href="http://golang.org/doc/code.html">golang</A> is an example of good
package management.</DIV>
<DIV>It`s interaction of the builder with github repositories is an interesting
idea. </DIV>
<DIV> </DIV>
<DIV>-----Original Message----- </DIV>
<DIV>From: Rodney M. Bates </DIV>
<DIV>Sent: Tuesday, June 02, 2015 6:18 PM </DIV>
<DIV>To: Olaf Wagner </DIV>
<DIV>Cc: m3devel </DIV>
<DIV>Subject: Re: [M3devel] A proposal, was m3cgc1: fatal error: *** bad M3CG
version stamp (0x100), expected 0x110 </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>On 06/02/2015 04:36 AM, Olaf Wagner wrote:</DIV>
<DIV>> On Mon, 01 Jun 2015 19:54:45 -0500</DIV>
<DIV>> "Rodney M. Bates" <rodney_bates@lcwb.coop> wrote:</DIV>
<DIV>></DIV>
<DIV>>> Here is a short-term proposal (i.e., without major
reorganization)</DIV>
<DIV>>> for the do-cm3*.sh scripts:</DIV>
<DIV>>></DIV>
<DIV>>> 1) 'build' only builds, as we seem to agree it should.</DIV>
<DIV>>> 2) a new option 'override' (and only 'override') causes an
override build</DIV>
<DIV>>> 3) a new option 'partialship' ships, as each package is done,
things that</DIV>
<DIV>>> will be needed to compile another
package that does a quake import on the</DIV>
<DIV>>> just-built package (I think this
means static library, if any, and .M3WEB),</DIV>
<DIV>>> but does not ship things that will
be used to execute the just-built package</DIV>
<DIV>>> (I think this means executable or
dynamic library). I'm not sure right off</DIV>
<DIV>>> hand which ship group things like
interface source files, etc. belong in.</DIV>
<DIV>></DIV>
<DIV>> I don't know how you will implement this and how it should fit into
the</DIV>
<DIV>> M3 package concept, unless you ship to a completely different
location,</DIV>
<DIV>> i.e. another package pool (but cm3 currently just supports one).</DIV>
<DIV>></DIV>
<DIV>> In my opinion the package system relies on the invariant that a
shipped</DIV>
<DIV>> (installed) package is completely consistent, i.e. the source
code</DIV>
<DIV>> interfaces correspond to the intermediate code interfaces and to
the</DIV>
<DIV>> binary equivalent of them (static and dynamic libraries). If I
understand</DIV>
<DIV>> you correctly, you want to give up this consistency in favour of
being</DIV>
<DIV>> able to do an easier bootstrap of the CM3 system.</DIV>
<DIV> </DIV>
<DIV>Yes, but we already must have a temporarily inconsistent state of
installation</DIV>
<DIV>today. This is a somewhat different kind of inconsistency, but
inconsistent,</DIV>
<DIV>nonetheless.</DIV>
<DIV> </DIV>
<DIV>I guess -partialship could do an additional final pass over the package
list,</DIV>
<DIV>doing a full ship. The inconsistent state would only last during a
single</DIV>
<DIV>user-requested step, which is about as short as it can get. My intent
was</DIV>
<DIV>that one would immediately do a full ship after a partialship, although
as</DIV>
<DIV>a separate command, thus restoring consistency.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>></DIV>
<DIV>> But bootstrapping a complex system is never easy and usually requires
some</DIV>
<DIV>> special or tricky steps. Ordinary use of the system, i.e. all other
applications,</DIV>
<DIV>> that just build on the standard tools, don't need this kind of
steps.</DIV>
<DIV>></DIV>
<DIV> </DIV>
<DIV>And my proposal is a simple, short-term way to provide somewhat more
flexible</DIV>
<DIV>options for just such special or tricky steps. It will work the same
way as now,</DIV>
<DIV>if you don't use the new options, and would allow Jay to get rid of the
hated</DIV>
<DIV>INSTALL_CM3_IN_BIN variable, with no loss of flexibility for special
steps.</DIV>
<DIV> </DIV>
<DIV>> If I could design (and implement) a better cm3 builder, I'd have one
with</DIV>
<DIV>> multiple package pools (shipping destinations, locations of
installed</DIV>
<DIV>> packages) and an integrated builder that knows all about the
package</DIV>
<DIV>> dependencies (so that we haven't to do that in scripts). The two
points</DIV>
<DIV>> are the only shortcomings in the cm3 build system in my opinion.</DIV>
<DIV>> The prjm tools of the ComPact sources was a step in this
direction:</DIV>
<DIV>> it can handle multiple pools of packages and their dependencies,
but</DIV>
<DIV>> is language independent, therefore too complex, and never got
integrated</DIV>
<DIV>> into the compiler builder.</DIV>
<DIV>></DIV>
<DIV> </DIV>
<DIV>Yes, absolutely. We need a greatly reworked build system for multiple
packages.</DIV>
<DIV>For building within a package, cm3's existing build is really quite
sophisticated.</DIV>
<DIV>I don't know of any other that detects the need for recompilation</DIV>
<DIV>on declaration-granularity. But it does very little with
inter-package</DIV>
<DIV>problems -- just detection of link-time inconsistencies, with
hopelessly</DIV>
<DIV>uninformative error messages. (I once set out to improve them, but
it</DIV>
<DIV>required more info in the .mx and .m3x files, with more incompatible</DIV>
<DIV>changes, and I only got one message improved a little bit, before I
gave</DIV>
<DIV>up for the time.)</DIV>
<DIV> </DIV>
<DIV>I agree, reworking it all is very desirable. It will take a lot of
rework.</DIV>
<DIV>I think we all agree that some kind of multi-layer, multi-destination</DIV>
<DIV>scheme is needed. This will probably entail disentangling the
source</DIV>
<DIV>and build directories from being interspersed in each package, or
something</DIV>
<DIV>equally perturbing to the existing system. It isn't going to be a
little</DIV>
<DIV>patch. I think my proposal will be small to implement and have no
impact</DIV>
<DIV>on anything existing, if you don't use the new options.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>> As for the shell scripts, I'm surprised that they have survived so
long;</DIV>
<DIV>> they just got created on the fly to support the building and
publication</DIV>
<DIV>> of the CM3 system as open source when we got the sources from
Critical</DIV>
<DIV>> Mass. They were never intended as a general user interface, but
only</DIV>
<DIV>> as tools for the CM3 maintainers, and later got used in the Hudson
CI.</DIV>
<DIV>></DIV>
<DIV>> BTW, if I find some time and access to suitable machines again,
I'd</DIV>
<DIV>> really like to set up a new CI system on Jenkins interfacing with
the</DIV>
<DIV>> Github infrastruture. But I won't make any promises here.</DIV>
<DIV>></DIV>
<DIV> </DIV>
<DIV>Yes, this would be very good. Priorities, priorities! :-(.</DIV>
<DIV> </DIV>
<DIV>> Olaf</DIV>
<DIV>></DIV>
<DIV> </DIV>
<DIV>-- </DIV>
<DIV>Rodney Bates</DIV>
<DIV>rodney.m.bates@acm.org</DIV></DIV></DIV></BODY></HTML>