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

Jay K jay.krell at cornell.edu
Thu Jul 22 16:47:22 CEST 2010


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
 		 	   		  


More information about the M3devel mailing list