This directory is a place holder while constructing the Go Language
toolchain for the Plan 9 environment.  It mirrors the Plan 9 root
namespace but allows us to have unique instances that address the
initial differences.  Eventually, the two namespaces ought to get
merged.

We will add content to the /go namespace as the need arises, for
example, we will only have /go/386 to start with, other architectures
will only follow when required for development.

Thu Jun 30 15:02:48 SAT 2011

It seems worthwhile to interpose a directory between the top level and
the architecture to cover the operating system.  The combination
os/arch is more practical if we choose to use Plan 9 as the build
platform, while the OS can be assimilated into $ROOT for building
purposes.

The Go release seems to have some failings regarding
cross-development, even its own bootstrapping under alien platforms,
I'm hoping to improve at least a little on this.  Being able to target
alien platforms in the Plan 9 environment would be in line with my
secondary objective of making the Go development toolchain the default
development tool on all PLan 9 platforms or, alternatively, to enhance
the Plan 9 development toolchain with the features brought in by the
Go developments.

Thu Jun 30 15:11:03 SAT 2011

Regarding the need to merge multiple strands of development into a
single target release and eventually to facilitate the convergence of
Go with Plan 9 as well as with p9p, I want to note that the Plan 9
"proto" model ought to be most useful in this regard.  It may be
necessary to add some features to the model, but the ability to
express a directory hierarchy in a text file is definitely in accord
with the need to produce a target hierarchy from two or more
independent sources.

Thu Jun 30 15:20:48 SAT 2011

I have no idea how long it will take me to get the Go runtime compiled
correctly on a Plan 9 platform by a version of the Go toolchain
(limited to 8a, 8l and 8c, for purposes of this discussion, we'll
discover soon enough what other tools may be needed - I already know
about goc2c) itself constructed on a Plan 9 platform.

I keep coming up against obstacles that resemble each other so much, I
don't feel like I'm making any progress whatsoever.  I am extremely
relunctant to perform the rather drastic surgery that will migrate the
target $ROOT from merely "/go" to "/go/plan9" because it is hard to be
sure that all possible fall-out from such surgery will be corrected
before it comes bak to bite me in the butt.  Ideally, only the "ROOT="
expression in mkfiles needs to be changed (and there are plenty
instances, so it's easy to miss one or more) and the scope at this
point is still limited, but the risk of failure isn't insignificant.

Then I must also make sure that the mkfile, possibly plural, required
to construct the runtime may itself need considerable effort.  At this
point the biggest issue is the selection of source/target modules to
deal with, the point of extending the platform description to a
two-level directory (os/arch as in plan9/386, say) is to provide a
safe location for the correct mkfile portions to be included in the
bigger building block.  Doing so ought to make it more practical to
list special cases that are OS or architecture dependent (and OS _and_
architecture dependent) separately, at the cost of having to repeat
occasional entries that are identical for the architecture even when
the OS is different.  I have a feeling the Go release deals with this
situation alreadym I don't have the time or the patience to
investigate this: it will resolve itself once Plan 9 is no longer the
sole focus.

Actually, the real issue is an understanding of the complex structure
involved in creating the runtime as a slightly unconventional Go
package: building packages is the general function, the Go runtime has
a few special twists and turns of its own (based on a superficial
examination).  I can't yet construct any Go packages (directly - I
could use a cross-compiled version of the Go tools, I suppose), but I
do need to understand the build mechanism before trying to apply it in
creating a mkfile to produce the runtime.

Also relevant here is the fact that the target "pkg" directory, very
much at the top of the Go release hierarchy has its own inner layer
labelled with the OS and architecture, this time combined into a
single name consisting of the OS and architecture names, in that
order, joined by an underscore (pkg/plan9_386 is the example I have at
hand).  I'm not sure that this is preferable to having distinct
directories, but for the time being we'll continue the convention.

This does rather interfere with the idea of having a "/go/plan9" $ROOT
if we're also going to have a "pkg/plan9_386" below it.  The current
layout is:

	go/
		386/
			bin/
			include/
			mkfile
			mkpkg
			mksyslib
		include/
		src/
			...
		pkg/
			plan9_386

An alternative might be (eventually):

	go/
		include/
		src/
		plan9/
			386/
				bin/
				include/
				pkg/

But we will not head in that direction just yet.

There seems to be a requirement for an OS directory in which to hold
OS dependent header files, specifically, the definitions required in a
package mkfile to deal with OS dependencies.  For the time being,
however, we'll skip changing the hierarchy, we'll just note future
directions.



