[M3devel] propose "output root" to replace shipping

[Rodney M. Bates]

I haven't had time to digest your proposal yet, but I have often been uncomfortable
about the current build system when building/bootstrapping itself.  It is probably
just lack of understanding of the right procedure, but I usually cringe before attempting
to bootstrap.  I have always been unclear about the sequence of when the newly built
components overlay the preexisting ones, so I would welcome some attention to this.

I would like to put in a vote for a way to build everything without overlaying
any existing components, so a bootstrapping operation can be easily restarted back
where it started.  Right now, for the compiler itself, I am meticulously saving side
copies of the compiler executables in /usr/local/cm3/bin every time.

On 03/20/2015 07:10 PM, Jay K wrote:
>   Building the current system fails in caltech-parser\parserlib\parserlib\test.
>
>
>
>   It tries to run an shipped klex but only the non-shipped one exist -- depending on the state of things.
>   But even if shipped exists, it likely shouldn't be using it.
>
>
>
>   This is a general problem we have been through somewhat before.
>
>
>
>   There are multiple parts to our current partial solution:
>
>
>   They can be seen here:
>    C:\dev2\cm3\m3-comm\netobj\src\netobj-ov.tmpl
>    C:\dev2\cm3\m3-comm\sharedobj\src\sharedobj-ov.tmpl
>    C:\dev2\cm3\m3-libs\libm3\src\bundleintf\bundle-ov.tmpl
>    C:\dev2\cm3\m3-ui\zeus\src\m3zume-ov.tmpl
>
>
>   And those various "build tools" use build_standalone()
>
>
>   This could imho be abstracted.
>
>
>   However, I propose where today we have:
>      source_root/m3-foo/bar/target/abc.obj
>      source_root/m3-foo/bar/target/bar.exe
>      source_root/m3-foo/bar/src/abc.m3
>
>
>    we instead have:
>       output_root/obj/bar/target/abc.obj
>       output_root/bin/target/bar.exe
>       output_root/bin/bar.exe link or stub to target/abc.exe
>       output_root/pkg/bar/...
>
>
>   or:
>       output_root_obj/bar/target/abc.obj
>       output_root_install/bin/target/bar.exe
>       output_root_install/bin/bar.exe link or stub to target/abc.exe
>       output_root_install/pkg/bar/...
>
>
>   and that "install" become just directory operations, like deleting old and move or copy output_root{_install} to it
>   just "script", not anything in cm3,
>
>
>   and then, on systems that support "origin" -- NT, Linux, Solaris, FreeBSD, NetBSD >= 5.0, we don't
>   use standalone for this, and on systems that don't support "origin", still use standalone
>
>
>   and then shipping goes away, as a package operation.
>   you can instead ship an output root.
>
>
>   and then this override stuff goes away also;
>   You bootstrap by copying in a few working files. Like make-dist.py does.
>   The system is reduced in size, as build_standalone falls away -- you can still use it,
>   but it won't be used usually.
>
>
>   The larger source tree would become readonly, as it should be.
>
>
>   Thoughts?
>
>
>   I believe Modula-3 was originally ahead of its time in having the readonly src directories,
>   but I believe time as passed it by, and what one really wants is a larger readonly tree of src directories/packages -- which
>   might as well not say "src", but preserve that instead of rearranging everything.
>
>
>   I know, I've heard, having the separate buildlocal / buildglobal is useful.
>   This doesn't elimine it that.
>   It replaces it with "multiple buildglobal".
>   Instead of having just the two options -- local and global -- you can create an arbitrary number of
>   "global" scopes by creating a new output_root, copying it from a preexisting one.
>
>
>   As well, it is obscure, but you can also have "multiple local" by changing BUILD_DIR.
>   But I don't think anyone does that. I think everyone leaves BUILD_DIR == TARGET.
>
>
>   This has several nice properties.
>   readonly source tree
>   less file copying possibly (depending on if final scripted ship is directory copy or move)
>   cm3 can stop implementing ship
>   no need to use build_standalone on most systems, including for cm3 itself (but it still works)
>
>
>
>   - Jay

-- 
Rodney Bates
rodney.m.bates at acm.org