<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><div> > Yes, absolutely. We need a greatly reworked build system for multiple packages.<br> > For building within a package, cm3's existing build is really quite sophisticated.</div><div><br></div><div><br></div><div>Exactly my thoughts for years. quake is nice and declarative for each package, and currently<br>does nothing for multiple packages. </div><div><br></div><div><br></div><div><br>How far would we get with the following:</div><div><br></div><div><br></div><div><br>include_dir to stitch together packages, the same as it stitches<br>directories within packages.</div><div><br></div><div><br></div><div>"Flush" the state at each Library() or Program() invocation?</div><div><br></div><div><br>Library and Program have to be last currently? So that would work?<br>Or they can be anywhere?</div><div><br></div><div><br></div><div><br>Furthermore, target directory either be:<br> 1) ./target -- might be what it'd do now, but is wrong choice <br> 2) under some new root, I'd suggest e.g. $CM3_OBJECT_ROOT. <br> cd anywhere, that is still it<br> 3) under some new new root, like go up from cwd until you find <br> special marker file; this would be building outside source tree entirely <br> 4) same as currently, wherever is Library()/Program(), go ../<target></div><div><br></div><div><br></div><div>If I'm wrong and library/program aren't last, well, then, just use a new name for include_dir?</div><div>That implicity "flushes"?</div><div><br></div><div><br></div><div>Anyone out there familiar with NT build.exe?</div><div>It very much resembles quake, but it does solve this last problem.</div><div>But it doesn't have intra-package include_dir.</div><div><br></div><div><br></div><div>it has dirs files for package stitching and sources files at the leaves, and only the leaves.</div><div>Something like m3core that has multiple directories would actually either be one flat directory,</div><div>or be composed of multiple static libraries, or more efficiently but esoteric, composed</div><div>of multiple TARGETTYPE=NOTARGET, which is like a library but leaves just lose object files</div><div>and doesn't make the .lib.</div><div><br></div><div><br></div><div>It looks like:</div><div>dirs file:</div><div> DIRS=a \</div><div> b \</div><div> c</div><div><br></div><div>sources file:</div><div>declarative like quake, but actually an nmake snippet instead of a quake snippet</div><div>escape hatch is more nmake, rather than more general purpose quake</div><div><br></div><div>I use this system a lot and quite like it.</div><div>Though it is obscure.</div><div><br></div><div>The point is -- declarative system with escape hatches (quake and modula-3 are the escape hatches) are a good design.</div><div>There are similar systems out there.</div><div>Ours isn't bad.</div><div><br></div><div><br></div><div>I think scons works this way too, the language being Python.</div><div><br></div><div><br></div><div>Now, I misstated something. Other than just walking dirs and flushing, except for m3cc, we can walk in the correct order</div><div>based on imports.</div><div>m3cc we can probably fix the order by importing from cm3, if we allow importing from a program.</div><div><br></div><div><br></div><div>Make sense?</div><div><br></div><div>Or replace everything with cmake or scons or even automake or such?</div><div>(Modula-3 was ahead of its time 20 years ago, but I think isn't any longer. It isn't really behind, but has near peers.)</div><div><br></div><div><br> - Jay<br><br><br><br><br></div><div><hr id="stopSpelling">From: dmuysers@hotmail.com<br>To: rodney.m.bates@acm.org; wagner@elegosoft.com<br>Date: Tue, 2 Jun 2015 18:39:35 +0200<br>CC: m3devel@elegosoft.com<br>Subject: Re: [M3devel] A proposal, was m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110<br><br>
<div dir="ltr">
<div style='color: rgb(0, 0, 0); font-family: "Arial"; font-size: 12pt;'>
<div><a href="http://golang.org/doc/code.html" target="_blank">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></div> </div></body>
</html>