[M3devel] m3override

[Olaf Wagner]

Quoting Jay K <jay.krell at cornell.edu>:

> ps: another suggestion here:
>  Don't use overrides in Hudson or package building.
>    Instead either build from scratch or with a new install that is a  
>  copy of the current (ie. of m3core/libm3). I alread automated this   
> in make-dist.py, which is a based on some other *.sh.
>    And then copy/swap at the end, or after some testing.
>    Except, er, um, either this is with $ORIGIN, or with relink upon   
> install -- not just copy/swap.
>
> The central sticking point in "all" this, in software configuration   
> in general -- is "run path".
>
>  And then, delete all the m3overrides files in the tree. And then   
> optionally remove the entire mechanism, or leave it alone, unused,   
> to bitrot.
>
> To some extent this is: don't bother implementing a mechanism in   
> cm3, just do it in scripts.

I've got no time for large changes, so we'll see if anybody cares
to implement anything.

>> M3 build system for large projects is based on the way the work
>> of the single developers can be split up and isolated. And in large
>
> Imagine a system composed of five pieces: bottom, almost bottom,   
> middle, almost top, top.
> The developer of "top" has it easy, he uses the "existing" bottom,   
> almost bottom, middle, almost top.
> What are the developers of any other piece to do?
> There are at least two factors to consider:
>   run path
>   public interfaces
>
> Even if public interfaces are unchanged, developer building a new   
> "almost top", must either put it where "top" expects, or rebuild top  
>  to get it from the new location.
>
> It has been said that LD_LIBRARY_PATH is for development scenarios.   
> So maybe that is the answer.
>
> To whatever extent systems are composed of just bottom and top and   
> nobody changes bottom, which I think is actually pretty common, no   
> problem, and people don't even understand the potential problem (I   
> theorize). But that seems..wrong.

Well, you see I've got the view of somebody building very large
systems (much larger than the CM3 distribution) for commerical use.
I've been working in such projects for the recent years; they're
programmed in C/C++ and Java (and make and ClearCase and Perl scripts
and ...), and build management and correct dependency tracking and
use is always a nightmare. M3 with its powerful abstractions would
be a great improvement there, but of course that's completely out of
the question. But nonetheless it's still interesting to think about
how M3 would actually compete in this domain.

 From a manager and user point of view, there are business functions
which may be attached to some real or virtual machine or to some computing
farm.

 From an architects view there are software layers, components with interfaces
and implementations, containers for running processes and threads etc.
And of course there are large external systems that are used or with which
data must be exchanged.

 From a build and release engineers point of view, there are hundred thousands
of files most of which exist in several hundred versions of which  
about a dozen
or more are part of valid and still supported or actively developed
configurations, that must build and play together consistently. And these
must be unit tested, integration tested, system tested and performance
tested.

Everything (more or less) changes continually, starting with the
requirements :-)

Nobody has a complete overview, but the developers must be isolated
and given a usable working configuration and setup to accomplish their
tasks. This is where abstraction and information hiding show the biggest
benefits.

No developer here is able to build the whole system; most are even not
allowed to read most of the code (if by accident or on purpose isn't
always clear). And of course development teams are distributed to
several sites around the world.

So I'm not thinking about minor technical issues like $ORIGIN or
LD_LIBRARY_PATH or about how we are best able to distribute the cm3
packages, but rather about M3 and its package and other abstraction
mechanisms would stand its ground in such a project. And if we should
really consider that or just be satisfied with our small CM3 community
and use cases.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                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
    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194