hypothetical directory structure for toolchain building

["Robert P. J. Day" <rpjday at mindspring dot com>]

  ok, interested in more comments -- here's how i've reconfigured
my directory structure for building potentially multiple toolchains,
with potentially more than one toolchain for the same target.
annotations at the bottom.  (note that a number of these directories
don't have to be under the same overarching directory structure, i'm 
just showing which directories are tightly related and which aren't.)

embedded/
	crosstool/
	kernels/
	patched-sources/
	projects/
		z-5500/
			stable-2.4.18/
				build/
				tools/
			exp-2.6.0/
				build/
				tools/
		sh-4/
			stable-2.4.22/
				build/
				tools/

  (first major side note.  i've shown all of these directories under
the top-level embedded/ directory just to keep things together, but
there's nothing that says that these directories need to be siblings.
all i'm trying to show is that the crosstool/ directory is independent
from the kernels/ directory, which is independent from the projects/
directory and so on, and they could be anywhere.  having them in one
place is just for aesthetics.)

  now, the rationale.  first, notice no "tarballs/" directory since, as i
mentioned earlier, there's no reason to believe that all of the sources
are in the same place.  you can set the initial variables GCC_SRC,
GLIBC_SRC and so on to point at the tarballs, wherever they might live.
(if you want an explicit tarballs/ directory, that's up to you, but
it's not required since the _SRC variables should refer to the full
filename of the source package, to allow for the flexibility.)

  next, the "kernels/" directory should contain all of the patched and
configured kernels, from which you can steal the three include files.
note that the same kernel version can be "made" for more than one
architecture, so you'll have to allow for combinations of kernel version/
arch, as in:

  kernels/
	2.4.18-arm/
	2.4.22-arm/
	2.6.0-test6-arm/
	2.4.18-ppc/
and so on.  how you choose to do this is up to you -- maybe you want
to break it down by version, then architecture, or vice versa:

  kernels/
	2.4.18/
		arm/
		ppc/
	2.4.22/
		arm/

or the other way around:

  kernels/
	arm/
		2.4.18/
		2.4.22/
	ppc/
		2.4.18/

whatever works for you.  (i'd be tempted to try the first of the two
approaches above, just to see if i could represent multiple architectures
with a single kernel source tree to save space.) in any event, the point
is to keep all kernel stuff in one place.

  note that configuring and building a kernel is not project-specific,
only architecture-specific, so none of this needs to be under a specific
project directory.

  next, the patched-sources/ directory -- simply the patched source
trees of gcc, glibc, binutils and so on.  as far as i can tell, all of
that is architecture- and project- independent:

  patched-sources/
	gcc-3.3/
	gcc-3.3.1/
	glibc-2.3.1/
	glibc-2.3.2/

and so on.  conceivably, a sizable directory if you want to be working
with multiple versions at the same time.

  and now, the projects/ directory, with one subdirectory for every
target/combocode combination.  as i mentioned previously, for maximum
flexibility, it might be useful to allow, for each target architecture,
building a toolchain with any combination of the gcc/glibc/binutils/
kernel packages.  that's why i suggested just adding an extra variable,
COMBOCODE, for each combination that you want to play with.  that
COMBOCODE is just your own cute pet name for that package combination, and
it's used to name the subdirectory.  it's totally backward compatible
since you can always just set COMBOCODE to the present gcc-glibc value if
you want (or even have the script do that automatically if COMBOCODE has
no value).

  so, depending on the targets and tool combos you're working with,
the entire projects/ directory might look like:

  projects/
	z-5500/
		regular-2.4.18/       COMBOCODE pet name
			build/
			tools
		test-2.6.0/           another COMBOCODE
			build/
			tools/
	renesas-sh4/
		robscombo/
			build/
			tools/

etc, etc.  a platform like the z-5500 already defines the target
architecture (arm), so notice that there's no architecture name in
the subdirectory structure.  why should there be?  the fact that the
target architecture is a z-5500 implies a target architecture of
arm already, there's no need to say it again.

  anyway, must hop in shower and get ready for class, so this was written
very stream-of-consciousness in one pass.  truthfully, i haven't even
finished digging through the final details of the toolchain construction,
but i'm well on my way to the reorganization i've described already, and
it's helped me immensely to understand the intricacies of building a
toolchain.  it may be that, once i figure out more, i'll realize this
directory structure is not appropriate, but that's life.

  comments?

rday


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com