extending crosstool to allow simultaneous executions

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

On Thu, 2 Dec 2004, Steven Scholz wrote:

> Robert P. J. Day 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:
> >
> >   BUILD_DIR=`pwd`/build/$TARGET/$TOOLCOMBO
> BTW I suggest
> since I use gcc-3.3.3-glibc-2.3.2-linux-2.6.8 _and_
> gcc-3.4.2-glibc-2.3.3-linux-2.4.27.

  i'd already thought of something like that, but it doesn't *quite*
solve the problem.  let me elaborate.

  as i read it, the whole point of creating that TOOLCOMBO variable is
to have a kind of "build ID", to distinguish one build from another
based on selecting a different combination of components, or based on
the target architecture.  in my case, that's why i get these lengthy
and cumbersome directory names like:


  but what's the value in all of the above?  if someone is dealing
with the same combination of components, then the current TOOLCOMBO
value is just overkill.  sure, it's informative, but it's also (for
most people, i suspect) stultifying redundant.  they already *know*
all of the above, they don't need to have it encoded in every single
build and every single results directory.

  a simple solution is to support an environment ID variable that one
can set to some meaningful string.  for me, say, "SE7705-big", which
*i* know means a toolchain for my SE7705 board, big endian.  and the
resulting directory structure would be:

  .../build/SE7705-big/...   (same for results directory)

and if one doesn't set the "ID" variable, then sure, it defaults to
TOOLCOMBO so it's backward compatible.  and if you choose to set the
ID variable, then you can start multiple builds simultaneously, and
none of them will step on each other.

  effectively, this idea *is* what's happening now.  the TOOLCOMBO
*is* a kind of build ID, it's just not being advertised that way.
making this simple extension would just make it clear what's really
going on.


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