[M3devel] getting outputs out of the source tree? reducing "ship"?

[Olaf Wagner]

You're writing from a perspective of building the complete CM3
distribution.

The designers of the package system intentionally made working in the
locality of one package easy. Package local build and ship are two
of the abstractions that make M3 well suited for large projects, where
the isolation of one package is the working context of one developer.

Actually, M3 offers many levels/layers of this kind of abstraction
that all have its use:

  o opaque type definition
  o partial revelation
  o modules with interfaces
  o generics for parametric type abstraction
  o packages with visible and invisible interfaces

I wouldn't wnat to loose any of them.

So I'm against changing anything regarding build and ship _as default_.

I don't object to beging able to override the output directory of
package building to another derived hierarchy, and to use that for
building the distribution archives.

If anybody wants to work on that, I'd expect it being written and
tested in isolation, until it is mature enough to actually replace
our existing infrastructure.

As you mention, it will be a lot of work.

Olaf

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

> Today we have:
>
>
> /cvsroot/pkg1/src
> outputs to /src/pkg1/target
>
>
> /cvsroot/pkg2/src
>
> outputs to /src/pkg2/target
>
>
>
> This was good for its time, better than e.g.
> outputs to /cvsroot/pkg1/src !
>
>
> However I want more.
>
>
> I want /cvsroot to be read only.
>
>
> So how about:
>  outputs to /cvsroot-out/pkg1/target
>
>
> This is probably easy to achieve.
> e.g. introduce BUILD_DIR_ROOT (or OUTPUT_ROOT) and it is defined,   
> prefix to BUILD_DIR.
> Probably would have to be accompanied by SOURCE_ROOT, prefix it as needed.
>  e.g. relative paths that go from output to source would need to be fixed.
>
>
>
> an maybe much more so, remove ship as a separate step:
>
>
>   outputs to /cvsroot-out/intermed/pkg1/target/*.mo 
>  
>
> outputs to /cvsroot-out/inst/lib/libpkg1.so The one and only copy. 
>   outputs to /cvsroot-out/inst/pkg/pkg1/src (maybe, separate ship   
> step! because is a waste when still testing)
>
>
> To "clean", you would have a choice of
>
>
> rm -rf /cvsroot-out/*
>
> or mkdir /cvsroot-out2
>  and point whatever environment variable at -inst2.
>    (possibly by copying cm3 into out2 and pointing $PATH at it)
>
>
> The buildlocal vs. buildglobal distinction would go away.
> buildlocal + ship (which you can't do today, except by copying   
> manually) would be equiv of
>   set CM3_OUTPUT_ROOT=/cm3-inst.new  (or again, copy   
> cm3/cm3cfg/config and set PATH)
>   build everything
>   To try it out, either change PATH, or
>
>
>   mv /cm-inst /cm3-inst.old
>   mv /cm3-inst.new /cm3-inst
>   unset CM3_OUTPUT_ROOT
>
>
>
> If you want to build less, and remain isolated like buildlocal:
>
>
>   cp -pr /cm3-inst $CM3_OUTPUT_ROOT
>   build seletctively
>   To try it out, either change PATH, or
>
>   mv /cm-inst /cm3-inst.old
>
>   mv /cm3-inst.new /cm3-inst
>
>   unset CM3_OUTPUT_ROOT
>
>
>
>
> One of the points is: the immediate output of compilation could have  
>  the same structure as the installation.
> Installation can be just renaming or copying directories. Not   
> reorganizing directory layout.
>
>
> buildglobal would be building into a new empty directory.-- instead   
> of build + don't ship
> buildglobal would be building top of the in-use directory -- instead  
>  of build + ship
>
> Positive consequences:
>   All unshipped binaries would work even if linked dynamically, e.g.  
>  with $ORIGIN, e.g. without static.
>   It still doesn't address systems without $ORIGIN though.
>
>
> There are major advantages either way -- ie. without ORIGIN you can   
> "stitch together" binaries whose
> paths have no relationship to each other, and you can move around at  
>  least the executables arbitrarily.
>   Though you can't move the libraries at all.
>    chroot is another way people deal with this -- using absolute   
> paths, but isolated from existing files.
>     It is kind of partial cheap virtual machine, chroot.
>
>
> Now, I have to admit, this is more of an intellectual exercise right  
>  now, as I don't have the time/inclination to do it soon. :(
>
>
>  
> - Jay
>



-- 
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