extending crosstool to allow simultaneous executions

Robert P. J. Day rpjday@mindspring.com
Thu Dec 2 16:45:00 GMT 2004


On Thu, 2 Dec 2004, Dan Kegel wrote:

> Steven Scholz wrote:
> > >   is it reasonable to extend crosstool slightly to allow simultaneous
> > > invocations if you're using the same TARGET and TOOLCOMBO, but just
> > > want to change something trivial -- say, some CONFIG flags?
> > >
> > >   as an example (and something i'm going to post on shortly), i might
> > > want to start two simultaneous runs building a chain for SH3, but one
> > > for big-endian and one for little-endian.  at the moment, i can't do
> > > that since the script "all.sh" has, hardcoded, the lines:
> > >
> > >   TOOLCOMBO=$GCC_DIR-$GLIBC_DIR
> > >   BUILD_DIR=`pwd`/build/$TARGET/$TOOLCOMBO
>
> Yes, it's reasonable, but the way I'd suggest you do it is by
> encoding the endian change in the TARGET name.  First, find out
> if there is already a convention in the gcc sources:
>   cd gcc-3.3.3/gcc
>   grep sh3 config.gcc
> This finds
>         sh3e*) target_cpu_default="SELECT_SH3E" ;;
>         sh3*)  target_cpu_default="SELECT_SH3" ;;
>         sh3e[lb]e*) target_cpu_default="SELECT_SH3E" ;;
>         sh3e[lb]*) target_cpu_default="SELECT_SH3" ;;
>         sh3e*) target_cpu_default="SELECT_SH3E" ;;
>         sh3*) target_cpu_default="SELECT_SH3" ;;
> So you should try
>   sh3eb-unknown-linux-gnu
>   sh3el-unknown-linux-gnu
> Alternate, the 2nd field in the target name is usually completely arbitrary,
> so you could also try
>   sh3-bigendian-linux-gnu
>   sh3-littleendian-linux-gnu
> or something similar.

  but that doesn't address my original point.  what the above does is
extend the TARGET idea ever so slightly to incorporate endianness.
ok, that's moderately useful.  but it doesn't support a completely
*general* mechanism of being able to build simultaneous toolchains
whose build properties might differ in an infinite number of ways.

  i might want to modify the version of binutils that i'm using.  i
might want to change the profiling or debugging or optimization flags
for the chain, and so on.  after a while, there's only so much you can
cram into the TARGET or TOOLCOMBO variables.

  a solution which has worked for me here is, as i mentioned earlier,
to just create a generic "ID" build identifier, which you can set to
an arbitrary string.  i might decide that some lengthy, complicated
set of build options should be called my "fred" build.  and another
totally different build might be identified by "barney".  what those
ID strings represent is only relevant to *me* and no one else, but it
guarantees that every single build is unique and doesn't conflict with
any other build.

  effectively, what's happening right now is that the
$TARGET/$TOOLCOMBO string *is* being used as the build ID.  to make
this more general is actually pretty trivial.  replace references to
$TARGET/$TOOLCOMBO with $BUILD_ID.  and, at the top of the build
script, add

  if [ -z "$BUILD_ID" ] ; then
	BUILD_ID=$TARGET/$TOOLCOMBO
  fi

and that's it.  if BUILD_ID is not set, it's totally backward
compatible.  if it *is* set, it's used instead.

  now, all of this depends on whether the crosstool scripts *require*
the directory structure to contain the levels of $TARGET/$TOOLCOMBO.
do they?

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



More information about the crossgcc mailing list