[M3devel] A proposal, was m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110

[Olaf Wagner]

On Mon, 01 Jun 2015 19:54:45 -0500
"Rodney M. Bates" <rodney_bates at lcwb.coop> wrote:

> Here is a short-term proposal (i.e., without major reorganization)
> for the do-cm3*.sh scripts:
> 
> 1) 'build' only builds, as we seem to agree it should.
> 2) a new option 'override' (and only 'override') causes an override build
> 3) a new option 'partialship' ships, as each package is done, things that
>     will be needed to compile another package that does a quake import on the
>     just-built package (I think this means static library, if any, and .M3WEB),
>     but does not ship things that will be used to execute the just-built package
>     (I think this means executable or dynamic library).  I'm not sure right off
>     hand which ship group things like interface source files, etc. belong in.

I don't know how you will implement this and how it should fit into the
M3 package concept, unless you ship to a completely different location,
i.e. another package pool (but cm3 currently just supports one).

In my opinion the package system relies on the invariant that a shipped
(installed) package is completely consistent, i.e. the source code
interfaces correspond to the intermediate code interfaces and to the
binary equivalent of them (static and dynamic libraries). If I understand
you correctly, you want to give up this consistency in favour of being
able to do an easier bootstrap of the CM3 system.

But bootstrapping a complex system is never easy and usually requires some
special or tricky steps. Ordinary use of the system, i.e. all other applications,
that just build on the standard tools, don't need this kind of steps.

If I could design (and implement) a better cm3 builder, I'd have one with
multiple package pools (shipping destinations, locations of installed
packages) and an integrated builder that knows all about the package
dependencies (so that we haven't to do that in scripts). The two points
are the only shortcomings in the cm3 build system in my opinion.
The prjm tools of the ComPact sources was a step in this direction:
it can handle multiple pools of packages and their dependencies, but
is language independent, therefore too complex, and never got integrated
into the compiler builder.

As for the shell scripts, I'm surprised that they have survived so long;
they just got created on the fly to support the building and publication
of the CM3 system as open source when we got the sources from Critical
Mass. They were never intended as a general user interface, but only
as tools for the CM3 maintainers, and later got used in the Hudson CI.

BTW, if I find some time and access to suitable machines again, I'd
really like to set up a new CI system on Jenkins interfacing with the
Github infrastruture. But I won't make any promises here.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 
               Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194