<div dir="ltr">Why can't we design and build a cm3 builder that supports these requirements? Relying on scripts seems entirely broken and an anathema to the portability of the CM3 system.<div><br></div><div>There seems to be enough experience to specify and design such a system and building it doesn't sound like it would be very difficult. I'm sure there would be enough volunteers to implement it since people's productivity is obviously being affected. Wouldn't we want to fix the problem for once and for all instead of endlessly hacking scripts?</div><div><br></div><div>Having a robust, reliable and portable end-to-end build system would also make it easier for people wanting to port and enhance the compiler, which would be a boost for the project.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 2, 2015 at 2:36 AM, Olaf Wagner <span dir="ltr"><<a href="mailto:wagner@elegosoft.com" target="_blank">wagner@elegosoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, 01 Jun 2015 19:54:45 -0500<br>
"Rodney M. Bates" <<a href="mailto:rodney_bates@lcwb.coop">rodney_bates@lcwb.coop</a>> wrote:<br>
<br>
> Here is a short-term proposal (i.e., without major reorganization)<br>
> for the do-cm3*.sh scripts:<br>
><br>
> 1) 'build' only builds, as we seem to agree it should.<br>
> 2) a new option 'override' (and only 'override') causes an override build<br>
> 3) a new option 'partialship' ships, as each package is done, things that<br>
>     will be needed to compile another package that does a quake import on the<br>
>     just-built package (I think this means static library, if any, and .M3WEB),<br>
>     but does not ship things that will be used to execute the just-built package<br>
>     (I think this means executable or dynamic library).  I'm not sure right off<br>
>     hand which ship group things like interface source files, etc. belong in.<br>
<br>
</span>I don't know how you will implement this and how it should fit into the<br>
M3 package concept, unless you ship to a completely different location,<br>
i.e. another package pool (but cm3 currently just supports one).<br>
<br>
In my opinion the package system relies on the invariant that a shipped<br>
(installed) package is completely consistent, i.e. the source code<br>
interfaces correspond to the intermediate code interfaces and to the<br>
binary equivalent of them (static and dynamic libraries). If I understand<br>
you correctly, you want to give up this consistency in favour of being<br>
able to do an easier bootstrap of the CM3 system.<br>
<br>
But bootstrapping a complex system is never easy and usually requires some<br>
special or tricky steps. Ordinary use of the system, i.e. all other applications,<br>
that just build on the standard tools, don't need this kind of steps.<br>
<br>
If I could design (and implement) a better cm3 builder, I'd have one with<br>
multiple package pools (shipping destinations, locations of installed<br>
packages) and an integrated builder that knows all about the package<br>
dependencies (so that we haven't to do that in scripts). The two points<br>
are the only shortcomings in the cm3 build system in my opinion.<br>
The prjm tools of the ComPact sources was a step in this direction:<br>
it can handle multiple pools of packages and their dependencies, but<br>
is language independent, therefore too complex, and never got integrated<br>
into the compiler builder.<br>
<br>
As for the shell scripts, I'm surprised that they have survived so long;<br>
they just got created on the fly to support the building and publication<br>
of the CM3 system as open source when we got the sources from Critical<br>
Mass. They were never intended as a general user interface, but only<br>
as tools for the CM3 maintainers, and later got used in the Hudson CI.<br>
<br>
BTW, if I find some time and access to suitable machines again, I'd<br>
really like to set up a new CI system on Jenkins interfacing with the<br>
Github infrastruture. But I won't make any promises here.<br>
<span class="HOEnZb"><font color="#888888"><br>
Olaf<br>
--<br>
Olaf Wagner -- elego Software Solutions GmbH -- <a href="http://www.elegosoft.com" target="_blank">http://www.elegosoft.com</a><br>
               Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<br>
phone: <a href="tel:%2B49%2030%2023%2045%2086%2096" value="+493023458696">+49 30 23 45 86 96</a>  mobile: <a href="tel:%2B49%20177%202345%20869" value="+491772345869">+49 177 2345 869</a>  fax: <a href="tel:%2B49%2030%2023%2045%2086%2095" value="+493023458695">+49 30 23 45 86 95</a><br>
Geschäftsführer: Olaf Wagner | Sitz: Berlin<br>
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<br>
</font></span></blockquote></div><br></div>