general thoughts on crosstool

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

  ok, here's a few thoughts i had on going over crosstool, and i'm curious
to know where i'm completely out to lunch before going any further.

  first, it seems to me that the crosstool tarball should be
self-contained to the extent that, while it won't contain the basic
toolchain component sources like gcc, glibc and so on, it *should* contain
the configuration files, the patches and so on.  more to the point, when
someone invokes crosstool, nothing should be *built* in the crosstool
directory.  the user should have to specify all inputs, and similarly all
destinations in terms of build directories.

  in terms of having to feed the crosstool program input, i can see three
separate variable value files (similar to the current .dat fies), with
the following breakdowns (i'm just making up the names arbitrarily):

  sources.conf:  pointers to all sources (which shouldn't need to reside
    in the same directory), such as gcc, glibc, binutils and so on

  arch.conf:  architecture-specific stuff, like TARGET, TARGET_CFLAGS and
    a reference to the kernel config file for this architecture

  build.conf:  all destinations, like BUILD_DIR, PREFIX and so on

i thought of this breakdown since there seemed to be a natural division
of all the input values into these three sections.  pretty much any of the
other variables would seem to fit in one of these three files.

sources.conf:

  this file will contain pointers to all of the components for building 
the toolchain, and i don't think they should be forced to reside in the
same directory.  i would call these values

GCC_SRC=
GLIBC_SRC=

and so on, since it's not clear what form those sources are in.  to be 
flexible, any one of them might be a gzipped tarball, a bzipped2 tarball,
an already-exploded directory, perhaps a zip file or maybe even an RPM.
in any case, each of those variables should be able to handle *any* of 
those forms, and crosstool should deal with it, yes?  (this means there's
really no TARBALLS directory anymore since there's no guarantee that all
sources are in the same place to start with.)

  it's also possible that someone might want to build a toolchain for the
same project using different combinations/versions of those tools.  at the
moment, the build really only supports different combinations of gcc and
glibc, since the script creates a subdirectory level of

TOOLCOMBO=$GCC_DIR-$GLIBC_DIR

but what if you want to try different combinations of gcc *and* glibc 
*and* binutils *and* perhaps a different kernel?  rather than build some
horrendously complex TOOLCOMBO combination, add one more line to the
sources.conf file:

COMBOCODE=

where you can take *any* combination of all the sources, and just give
a code name to that combination.  that codename would become the new 
subdirectory level.  this would be perfectly backward compatible since
you could always just given the COMBOCODE variable the explicit value of
gcc-glibc as before, but with this approach, you can be much more 
flexible.  so a sample sources.conf file might be:

GCC_SRC=/a/b/c/gcc-3.3.1.tar.gz                (gzipped tarball)
GLIBC_SRC=/d/e/f/glibc-2.3.2.tar.bz2           (bzip2 tarball)
BINUTILS_SRC=/tmp/binutils-1.4.src.rpm         (source RPM)
KERNEL_SRC=/usr/src/linux-2.6.0-test6          (exploded directory)
COMBOCODE=exp_2.6.0                            (arbitrary name for this 
                                                combination)

arch.conf:

TARGET=
TARGET_CFLAGS=
KERNEL_CONFIG_FILE=

  (this could be a bit tricky since it's not clear a single kernel config
file will be sufficient based on having a choice for the kernel version.)


build.conf:

PREFIX=
BUILD_DIR=

  as far as i can tell, that's pretty much all the input you have to feed
to crosstool to get things started.  comments?

  more questions coming shortly.

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