[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