revamped gdb_mbuild.sh

revamped gdb_mbuild.sh

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 2060 bytes --]

Richard,

Finally got to trying the gdb_mbuild.sh script and, in the process, 
integrated some, er, `new features' from my old local script:

The changes are:


- restartable

Instead of starting over from scratch, it tries to continue on from 
where the last run left off (after being CNTRL-Ced or failing).  To 
force a complete rebuild of each target, use the option:

`-f' (force) will force a new run


- stop on failure

The script, by default, aborts on the first failed build.  The 
assumption is that the problem will be fixed and then the script 
re-started.  This can be overriden with the option:

`-k' (keep going) will force the script to try and build everything 
possible (the flag is passed to make as well).


- parallel

Rather than having separate configure and build phases (waiting on all 
the configures to finish before starting the builds), this script 
directly starts the parallel sub-shells.  Each sub-shell then tries to 
do a full configure, build and run for its target.  The number of jobs 
is specified with the option:

`-j <maxjobs>' controls the number of parallel jobs

(the implementation isn't perfect mind, it misses a second job finishing 
before a first).

- testing

In addition to checking the configure and build, the script also tries 
to run the built GDB to the point where it checks that '(gdb) maint 
print architecture' succeeds.

(NB: The h8500hms target currently barfs when run, I think I might 
propose that it be booted out of the build list).


- selecting targets

A sub-set of targets can be selected using the option:

`-e <targexp>' Select a subset of the targets using the (grep) regular 
expression <targexp>.  Multiple expressions can be specified.


- the output was changed vis:
mn10300-elf ,-Werror ...
ns32k-netbsd ,-Werror ...
... configuring mn10300-elf
... configuring ns32k-netbsd
... compiling ns32k-netbsd
... compiling mn10300-elf
... running ns32k-netbsd
... ns32k-netbsd built
... running mn10300-elf
... mn10300-elf built

Comments (for instance on the choice of options),

Andrew


[-- Attachment #2: gdb_mbuild.sh --]
[-- Type: text/plain, Size: 6349 bytes --]

#!/bin/sh

#  Multi-build script for testing compilation of all maintained configs of GDB.
#  Copyright (C) 2002  Free Software Foundation, Inc.
#  Contributed by Richard Earnshaw  (rearnsha@arm.com)

#  This program is free software; you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.

#  This program is distributed in the hope that it will be useful,
#  but WITHOUT ANY WARRANTY; without even the implied warranty of
#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#  GNU General Public License for more details.

#  You should have received a copy of the GNU General Public License
#  along with this program; if not, write to the Free Software
#  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

usage() {
    cat <<EOF
Usage: gdb_mbuild.sh [ <options> ... ] <srcdir> <builddir>
 Options:
  -j <maxjobs>  Run <maxjobs> in parallel.  On a single cpu machine,
                2 is recommended.
  -k            Keep going.  Do not stop after the first build fails.
  -e <regexp>   Regular expression for selecting the targets to build.
  -f            Force rebuild.  Even rebuild previously built directories.
 Environment variables examined (with default if not defined):
  MAKE (make)"
 Note: Everything in <builddir>/gdb-allcross will be blown away.
EOF
    exit 1;
}

### COMMAND LINE OPTIONS

maxjobs=1
keepgoing=false
force=false
targexp=""
while test $# -gt 0
do
    case "$1" in
    -j )
	# Number of parallel make jobs (you probably want about 2 jobs
	# per cpu for maximum throughput)
	shift
	test $# -ge 1 || usage
	maxjobs=$1
	;;
    -k )
	# Should we soldier on after the first build fails?
	keepgoing=true
	;;
    -e )
	# A regular expression for selecting targets
	shift
	test $# -ge 1 || usage
	targexp="${targexp} -e ${1}"
	;;
    -f )
	# Force a rebuild
	force=true ; shift ;;
    -* ) usage ;;
    *) break ;;
    esac
    shift
done


### COMMAND LINE PARAMETERS

if test $# -ne 2
then
    usage
fi

# Convert these to absolute directory paths.

# Where the sources live
srcdir=`cd $1 && /bin/pwd` || exit 1

# Where the builds occur
builddir=`cd $2 && /bin/pwd` || exit 1


### ENVIRONMENT PARAMETERS

# Version of make to use
make=${MAKE:-make}
MAKE=${make}
export MAKE


# Where to look for the list of targets to test
maintainers=${srcdir}/gdb/MAINTAINERS
if [ ! -r ${maintainers} ]
then
    echo Maintainers file ${maintainers} not found
    exit 1
fi

# Get the list of targets and the build options
alltarg=`cat ${maintainers} | tr -s '[\t]' '[ ]' | sed -n '
/^[ ]*[-a-z0-9\.]*[ ]*[(]*--target=.*/ !d
s/^.*--target=//
s/).*$//
h
:loop
  g
  /^[^ ]*,/ !b end
  s/,[^ ]*//
  p
  g
  s/^[^,]*,//
  h
b loop
:end
p
' | if test "${targexp}" = ""
then
    grep -v -e broken -e OBSOLETE
else
    grep ${targexp}
fi`


# Run several jobs in parallel.
set --


# Usage: fail <message> <test-that-should-succeed>.  Should the build
# fail?  If the test is true, and we don't want to keep going, print
# the message and shoot everything in sight and abort the build.

fail ()
{
    msg="$1" ; shift
    if test "$@"
    then
	echo "${target}: ${msg}"
	if ${keepgoing}
	then
	    exit 0
	else
	    kill $$
	    exit 1
	fi
    fi
}


# Warn the user of what is comming, print the list of targets
echo "$alltarg"
echo ""


# For each target, configure and build it.
echo "$alltarg" | while true
do

    # Keep forking jobs until we've exceed our job capacity

    while test $# -lt ${maxjobs} && read target gdbopts simopts
    do

	(
	    trap "exit 1"  1 2 15
	    dir=${builddir}/${target}

	    # Should a scratch rebuild be forced?
	    if ${force}
	    then
		rm -rf ${dir}
	    fi
	    
	    # Don't bother re-building a built target (indicated by
	    # ${dir} being a file).
	    if test -f ${dir}
	    then
		#echo "${target}: already built"
		exit 0
	    fi

	    echo ${target} ${gdbopts} ${simopts} ...

	    # The config options
	    __target="--target=${target}"
	    __enable_gdb_warnings=`test -z "${gdbopts}" \
		|| echo "--enable-gdb-warnings=${gdbopts}"`
	    __enable_sim_warnings=`test -z "${simopts}" \
		|| echo "--enable-sim-warnings=${simopts}"`

	    # Did the previous configure attempt fail?  If it did
	    # restart from scratch.
	    if test ! -r ${dir}/gdb/Makefile
	    then
		rm -rf ${dir}
		mkdir -p ${dir}
	    fi

	    # From now on, we're in this target's build directory
	    cd ${dir} || exit 1

	    # Configure, if not already.
	    if test ! -r gdb/Makefile
	    then
		echo "... configuring ${target}"
		trap 'echo Removing partially configured ${target} directory ...; rm -rf ${dir}; exit 1' 1 2 15
		${srcdir}/configure \
		    ${__target} \
		    ${__enable_gdb_warnings} \
		    ${__enable_sim_warnings} \
		> Config.log 2>&1
		trap "exit 1"  1 2 15
	    fi
	    fail "configure failed" ! -r gdb/Makefile

	    # Build, if not built.
	    if test ! -x gdb/gdb -a ! -x gdb/gdb.exe
	    then
		echo "... compiling ${target}"
		${make} all-gdb > Build.log 2>&1
	    fi
	    fail "compile failed" ! -x gdb/gdb -a ! -x gdb/gdb.exe
	
	    # Check that the built GDB can at least print it's architecture.
	    echo "... running ${target}"
	    rm -f core gdb.core ${dir}/gdb/x
	    cat <<EOF > x
maint print architecture
quit
EOF
	    ./gdb/gdb -batch -nx -x x > Arch.log 2>&1 < /dev/null
	    fail "gdb dumped core" -r core -o -r gdb.core
	    fail "gdb printed no output" ! -s Arch.log
	    grep -e internal-error Arch.log && fail "gdb panic" 1

	    # Replace the build directory with a file as semaphore
	    # that stops a rebuild. (should the logs be saved?)
	    cd ${builddir}
	    rm -f ${target}.tmp
	    mv ${target}/Arch.log ${target}.tmp
	    rm -rf ${target}
	    mv ${target}.tmp ${target}

	    # Success!
	    echo "... ${target} built"

	) &

	# Append this to the list of things to wait for.  Grr, there
	# is a race condition as the cntrl-c could come in before the
	# trap is updated.
	trap "echo Killing jobs $@ $!; kill $@ $!; wait ; exit 1" 1 2 15
	set -- "$@" $!

    done

    # If we've got zero jobs, we're finished
    if test $# -eq 0
    then
	break
    fi

    # Reap the first running process, then starting again
    wait $1 ; shift

done

exit 0

Re: revamped gdb_mbuild.sh

[Richard Earnshaw]

> Richard,
> 
> Finally got to trying the gdb_mbuild.sh script and, in the process, 
> integrated some, er, `new features' from my old local script:
> 

Looks pretty good to me.  My only comment is that we loose the ability to 
run gnumake with -j <n> replacing it with simultaneous configures/builds 
of different targets.  That means a higher transient disk usage (storage) 
which would be a marginal problem for me due to lack of disk quota on the 
multi-way machines... ;-(  But that's me thinking about my environment, so 
it isn't a major objection

R.

Re: revamped gdb_mbuild.sh

[Andrew Cagney]

> Richard,
>> 
>> Finally got to trying the gdb_mbuild.sh script and, in the process, 
>> integrated some, er, `new features' from my old local script:
>> 
> 
> 
> Looks pretty good to me.  My only comment is that we loose the ability to 
> run gnumake with -j <n> replacing it with simultaneous configures/builds 
> of different targets.  That means a higher transient disk usage (storage) 
> which would be a marginal problem for me due to lack of disk quota on the 
> multi-way machines... ;-(  But that's me thinking about my environment, so 
> it isn't a major objection

I was wondering about a schema where one resource was allocated to 
configure while the remaining N-1 were allocated to a single build. 
That would mean an even faster turnaround on the first build (which I've 
found is what I'm after :-).

I guess we just wonder ...

Andrew

Re: revamped gdb_mbuild.sh

[Richard Earnshaw]

> > Richard,
> >> 
> >> Finally got to trying the gdb_mbuild.sh script and, in the process, 
> >> integrated some, er, `new features' from my old local script:
> >> 
> > 
> > 
> > Looks pretty good to me.  My only comment is that we loose the ability to 
> > run gnumake with -j <n> replacing it with simultaneous configures/builds 
> > of different targets.  That means a higher transient disk usage (storage) 
> > which would be a marginal problem for me due to lack of disk quota on the 
> > multi-way machines... ;-(  But that's me thinking about my environment, so 
> > it isn't a major objection
> 
> I was wondering about a schema where one resource was allocated to 
> configure while the remaining N-1 were allocated to a single build. 
> That would mean an even faster turnaround on the first build (which I've 
> found is what I'm after :-).
> 
> I guess we just wonder ...
> 
> Andrew
> 
> 


How about -c <x> -j <y>?  Ie x configures in parallel & y make jobs in 
parallel?

R.

Re: revamped gdb_mbuild.sh

[Andrew Cagney]

> How about -c <x> -j <y>?  Ie x configures in parallel & y make jobs in 
> parallel?

In that script, a mindless implementation would result in:

	-c 2 -j 2

creating two tasks (-c 2), each running 'make -j 2' (for jobs at the max).

Is that your intent?  Or, as I suspect, try to sustain two configures 
and a single 'make -j 2'.

Andrew

Re: revamped gdb_mbuild.sh

[David Carlton]

Just checking: if I do 'gdb_mbuild.sh -f -k' I'll get behavior like
the current script?  (Well, the current script plus a small amount of
testing.)  I usually run this overnight, so I like the current
behavior.

David Carlton
carlton@math.stanford.edu

Re: revamped gdb_mbuild.sh

[Richard Earnshaw]

> 
> > How about -c <x> -j <y>?  Ie x configures in parallel & y make jobs in 
> > parallel?
> 
> In that script, a mindless implementation would result in:
> 
> 	-c 2 -j 2
> 
> creating two tasks (-c 2), each running 'make -j 2' (for jobs at the max).
> 
> Is that your intent?  Or, as I suspect, try to sustain two configures 
> and a single 'make -j 2'.
> 
> Andrew
> 
> 


Yep, it would mean that in my case you could effectively run -c 1 -j 10 
and get fast builds with only the configures dropping down to single 
threaded (which would get most of the parallelism with the least transient 
disk space use) -- or have -c 2 -j 5 for a bit more configure parallelism 
with less make parallelism.  It would be a trade off that could be made by 
each user, and the load would be the product of the two.

R.

Re: revamped gdb_mbuild.sh

[Andrew Cagney]

(Technical nit, -j 10 (or -j 2), right now doesn't work.  The sim 
directory, well at least mn10300, has some missing dependencies :-()

> 
> 
> Yep, it would mean that in my case you could effectively run -c 1 -j 10 
> and get fast builds with only the configures dropping down to single 
> threaded (which would get most of the parallelism with the least transient 
> disk space use) -- or have -c 2 -j 5 for a bit more configure parallelism 
> with less make parallelism.  It would be a trade off that could be made by 
> each user, and the load would be the product of the two.

M'kay (already appears to work).  How about `-b N' where `-b' stands for 
``build'' (configure, make, run, ...) for the option name.

Andrew

Re: revamped gdb_mbuild.sh

[Richard Earnshaw]

> (Technical nit, -j 10 (or -j 2), right now doesn't work.  The sim 
> directory, well at least mn10300, has some missing dependencies :-()
> 

There you are, it's found one bug already :-) 

> > 
> > 
> > Yep, it would mean that in my case you could effectively run -c 1 -j 10 
> > and get fast builds with only the configures dropping down to single 
> > threaded (which would get most of the parallelism with the least transient 
> > disk space use) -- or have -c 2 -j 5 for a bit more configure parallelism 
> > with less make parallelism.  It would be a trade off that could be made by 
> > each user, and the load would be the product of the two.
> 
> M'kay (already appears to work).  How about `-b N' where `-b' stands for 
> ``build'' (configure, make, run, ...) for the option name.

Don't mind what they're called (provided they aren't 100 characters long 
:-)

R.

Re: revamped gdb_mbuild.sh

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 2244 bytes --]

Ok,

Attached is an updated script:

> The changes are:
> 
> 
> - restartable
> 
> Instead of starting over from scratch, it tries to continue on from where the last run left off (after being CNTRL-Ced or failing).  To force a complete rebuild of each target, use the option:
> 
> `-f' (force) will force a new run
> 
> 
> - stop on failure
> 
> The script, by default, aborts on the first failed build.  The assumption is that the problem will be fixed and then the script re-started.  This can be overriden with the option:
> 
> `-k' (keep going) will force the script to try and build everything possible (the flag is passed to make as well).
> 
> 
> - parallel

It is possible to specify parallism at two levels.  Firstly the number 
of builds, and secondly the number of jobs MAKE tries to sustain.  Two 
options control this:

`-b MAXBUILDS' The number of builds to run in parallel.
`-j MAXJOBS' The number of jobs, whithin a build, that MAKE should run 
in parallel (using `make -j MAXJOBS').

These options are orthoginal, `-b 3 -j 2' will result in the script 
running up to three simultaneous `make -j 2'.

> - testing
> 
> In addition to checking the configure and build, the script also tries to run the built GDB to the point where it checks that '(gdb) maint print architecture' succeeds.
> 
> (NB: The h8500hms target currently barfs when run, I think I might propose that it be booted out of the build list).
> 
> 
> - selecting targets
> 
> A sub-set of targets can be selected using the option:
> 
> `-e <targexp>' Select a subset of the targets using the (grep) regular expression <targexp>.  Multiple expressions can be specified.

- more verbose output

By default the output from the configure and build is supressed (saved 
to a log file).  This can be disabled with:

-v (verbose) Provide more verbose output (e.g., output the configure, 
build and run results to stdout).

This is very useful from within emacs.  Something like `M-X compile' 
`./gdb_build.sh -v .. /tmp' works.


David, yes, `gdb_build.sh -k -f' should give you back something like the 
old behavior.

Richard, should `-j 2' be the default?  Now that this doesn't lead to 
two parallel configures (which is what I think hammers the poor host).

Andrew

[-- Attachment #2: gdb_mbuild.sh --]
[-- Type: text/plain, Size: 7552 bytes --]

#!/bin/sh

#  Multi-build script for testing compilation of all maintained configs of GDB.
#  Copyright (C) 2002  Free Software Foundation, Inc.
#  Contributed by Richard Earnshaw  (rearnsha@arm.com)

#  This program is free software; you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.

#  This program is distributed in the hope that it will be useful,
#  but WITHOUT ANY WARRANTY; without even the implied warranty of
#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#  GNU General Public License for more details.

#  You should have received a copy of the GNU General Public License
#  along with this program; if not, write to the Free Software
#  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

usage() {
    cat <<EOF
Usage: gdb_mbuild.sh [ <options> ... ] <srcdir> <builddir>
 Options:
  -j <makejobs>  Run <makejobs> in parallel.  Passed to make.
		 On a single cpu machine, 2 is recommended.
  -b <maxbuilds> Run <maxbuild> builds in parallel.
		 On a single cpu machine, 1 is recommended.
  -v             Be more (and more, and more) verbose.
  -k             Keep going.  Do not stop after the first build fails.
  -e <regexp>    Regular expression for selecting the targets to build.
  -f             Force rebuild.  Even rebuild previously built directories.
 Environment variables examined (with default if not defined):
  MAKE (make)"
 Note: Everything in <builddir>/gdb-allcross will be blown away.
EOF
    exit 1;
}

### COMMAND LINE OPTIONS

makejobs=
maxbuilds=1
keepgoing=false
force=false
targexp=""
verbose=0
while test $# -gt 0
do
    case "$1" in
    -j )
	# Number of parallel make jobs.
	shift
	test $# -ge 1 || usage
	makejobs="-j $1"
	;;
    -b | -c )
	# Number of builds to fire off in parallel.
	shift
	test $# -ge 1 || usage
	maxbuilds=$1
	;;
    -k )
	# Should we soldier on after the first build fails?
	keepgoing=true
	;;
    -e )
	# A regular expression for selecting targets
	shift
	test $# -ge 1 || usage
	targexp="${targexp} -e ${1}"
	;;
    -f )
	# Force a rebuild
	force=true ; shift ;;
    -v )
	# Be more, and more, and more, verbose
	verbose=`expr ${verbose} + 1`
	;;
    -* ) usage ;;
    *) break ;;
    esac
    shift
done


### COMMAND LINE PARAMETERS

if test $# -ne 2
then
    usage
fi

# Convert these to absolute directory paths.

# Where the sources live
srcdir=`cd $1 && /bin/pwd` || exit 1

# Where the builds occur
builddir=`cd $2 && /bin/pwd` || exit 1


### ENVIRONMENT PARAMETERS

# Version of make to use
make=${MAKE:-make}
MAKE=${make}
export MAKE


# Where to look for the list of targets to test
maintainers=${srcdir}/gdb/MAINTAINERS
if [ ! -r ${maintainers} ]
then
    echo Maintainers file ${maintainers} not found
    exit 1
fi

# Get the list of targets and the build options
alltarg=`cat ${maintainers} | tr -s '[\t]' '[ ]' | sed -n '
/^[ ]*[-a-z0-9\.]*[ ]*[(]*--target=.*/ !d
s/^.*--target=//
s/).*$//
h
:loop
  g
  /^[^ ]*,/ !b end
  s/,[^ ]*//
  p
  g
  s/^[^,]*,//
  h
b loop
:end
p
' | if test "${targexp}" = ""
then
    grep -v -e broken -e OBSOLETE
else
    grep ${targexp}
fi`


# Run several jobs in parallel.
set --


# Usage: fail <message> <test-that-should-succeed>.  Should the build
# fail?  If the test is true, and we don't want to keep going, print
# the message and shoot everything in sight and abort the build.

fail ()
{
    msg="$1" ; shift
    if test "$@"
    then
	echo "${target}: ${msg}"
	if ${keepgoing}
	then
	    exit 1
	else
	    kill $$
	    exit 1
	fi
    fi
}


# Usage: log <logfile>.  Write standard input to <logfile> and (if
# verbose) stdout.

log ()
{
    if test ${verbose} -gt 0
    then
	tee $1
    else
	cat > $1
    fi
}



# Warn the user of what is comming, print the list of targets
echo "$alltarg"
echo ""


# For each target, configure and build it.
echo "$alltarg" | while true
do

    # Keep forking builds until we've exceed our build capacity

    while test $# -lt ${maxbuilds} && read target gdbopts simopts
    do

	(
	    trap "exit 1"  1 2 15
	    dir=${builddir}/${target}

	    # Should a scratch rebuild be forced?
	    if ${force}
	    then
		echo ... forcing ${target}
		rm -rf ${dir}
	    fi
	    
	    # Don't bother re-building a built target (indicated by
	    # ${dir} being a file).
	    if test -f ${dir}
	    then
		echo "${target}"
		exit 0
	    fi

	    echo ${target} ...

	    # Did the previous configure attempt fail?  If it did
	    # restart from scratch.
	    if test -d ${dir} -a ! -r ${dir}/gdb/Makefile
	    then
		echo ... removing partially configured ${target}
		rm -rf ${dir}
		if test -d ${dir}
		then
		    echo "${target}: unable to remove directory ${dir}"
		    exit 1
		fi
	    fi

	    # From now on, we're in this target's build directory
	    mkdir -p ${dir}
	    cd ${dir} || exit 1

	    # Configure, if not already.
	    if test ! -r gdb/Makefile
	    then
		# The config options
		__target="--target=${target}"
		__enable_gdb_warnings=`test -z "${gdbopts}" \
		    || echo "--enable-gdb-warnings=${gdbopts}"`
		__enable_sim_warnings=`test -z "${simopts}" \
		    || echo "--enable-sim-warnings=${simopts}"`
		echo ... configure ${target} \
		    ${__enable_gdb_warnings} \
		    ${__enable_sim_warnings}
		trap "echo Removing partially configured ${dir} directory ...; rm -rf ${dir}; exit 1" 1 2 15
		${srcdir}/configure \
		    ${__target} \
		    ${__enable_gdb_warnings} \
		    ${__enable_sim_warnings} \
		2>&1 | log Config.log
		trap "exit 1"  1 2 15
	    fi
	    fail "configure failed" ! -r gdb/Makefile

	    # Build, if not built.
	    if test ! -x gdb/gdb -a ! -x gdb/gdb.exe
	    then
		echo ... make ${makejobs} ${target}
		${make} ${makejobs} all-gdb 2>&1 | log Build.log
	    fi
	    fail "compile failed" ! -x gdb/gdb -a ! -x gdb/gdb.exe
	
	    # Check that the built GDB can at least print it's architecture.
	    echo ... run ${target}
	    rm -f core gdb.core ${dir}/gdb/x
	    cat <<EOF > x
maint print architecture
quit
EOF
	    ./gdb/gdb -batch -nx -x x 2>&1 | log Gdb.log
	    fail "gdb dumped core" -r core -o -r gdb.core
	    fail "gdb printed no output" ! -s Gdb.log
	    grep -e internal-error Gdb.log && fail "gdb panic" 1

	    # Replace the build directory with a file as semaphore
	    # that stops a rebuild. (should the logs be saved?)
	    cd ${builddir}
	    rm -f ${target}.tmp
	    mv ${target}/Gdb.log ${target}.tmp
	    rm -rf ${target}
	    mv ${target}.tmp ${target}

	    # Success!
	    echo ... ${target} built

	) &

	# Append this to the list of things to wait for.  Grr, there
	# is a race condition as the cntrl-c could come in before the
	# trap is updated.
	set -- $* $!
	trap "echo Killing $*; kill $*; wait ; exit 1" 1 2 15

    done

    # If we've got zero jobs, we're finished
    if test $# -eq 0
    then
	break
    fi

    # Reap the first running process.  Unfortunatly, this doesn't help
    # if that process turns out to be the slowest.  Anyone got a
    # better suggestion?
    wait $1 ; shift

    # Prune the remaining processes, cuting out any others that have
    # finished.  This hopefully helps a little with the above problem
    # by maximising the number of jobs started each time round the
    # loop.
    jobs=""
    while test $# -gt 0
    do
	# still running?
	if kill -0 $1 > /dev/null 2>&1
	then
	    jobs="${jobs} $1"
	else
	    wait $1
	fi
	shift
    done
    set -- ${jobs}

done

exit 0

Re: revamped gdb_mbuild.sh

[Andrew Cagney]

PS: Something I forgot to mention.

The new script, once it has successfully configured, built, and run a 
target, replaces the BUILDDIR/TARGET directory with a BUILDDIR/TARGET 
file (-f removes this, this is how the script knows to not try to re-do 
a build).

Anyway, the significant thing here is that the file contains the output 
from the TARGET's ``(gdb) maint print architecture'' command.  Having 
that output for each architectures available [suddenly] makes it 
possible to examine/compare all the settings and, consequently, change 
those settings to something more logical.

enjoy,
Andrew

Re: revamped gdb_mbuild.sh

[Richard Earnshaw]

ac131313@redhat.com said:
> Richard, should `-j 2' be the default?  Now that this doesn't lead to
> two parallel configures (which is what I think hammers the poor host).
> 

No, since I suspect output is harder to parse (interleaved messages).

R.

Re: revamped gdb_mbuild.sh

[Richard Earnshaw]

> PS: Something I forgot to mention.
> 
> The new script, once it has successfully configured, built, and run a 
> target, replaces the BUILDDIR/TARGET directory with a BUILDDIR/TARGET 
> file (-f removes this, this is how the script knows to not try to re-do 
> a build).
> 
> Anyway, the significant thing here is that the file contains the output 
> from the TARGET's ``(gdb) maint print architecture'' command.  Having 
> that output for each architectures available [suddenly] makes it 
> possible to examine/compare all the settings and, consequently, change 
> those settings to something more logical.
> 
> enjoy,
> Andrew
> 

What happens to the build logs?  Do we keep those?

R.

Re: revamped gdb_mbuild.sh

[Andrew Cagney]

> PS: Something I forgot to mention.
>> 
>> The new script, once it has successfully configured, built, and run a 
>> target, replaces the BUILDDIR/TARGET directory with a BUILDDIR/TARGET 
>> file (-f removes this, this is how the script knows to not try to re-do 
>> a build).
>> 
>> Anyway, the significant thing here is that the file contains the output 
>> from the TARGET's ``(gdb) maint print architecture'' command.  Having 
>> that output for each architectures available [suddenly] makes it 
>> possible to examine/compare all the settings and, consequently, change 
>> those settings to something more logical.
>> 
>> enjoy,
>> Andrew
>> 
> 
> 
> What happens to the build logs?  Do we keep those?

At present both build and config logs, and the build directory get 
removed.  Only architecture output is left.

I think this is ok since, unlike before, the command is restartable.  If 
the build fails, just restart it with a more verbose option(1).

?
Andrew

(1) Although this doesn't help the mn10300's -j 2 build problem.  The 
second run mysteriously worked.

Re: revamped gdb_mbuild.sh

[David Carlton]

On Wed, 27 Nov 2002 13:05:35 -0500, Andrew Cagney <ac131313@redhat.com> said:

>>> The new script, once it has successfully configured, built, and run
>>> a target, replaces the BUILDDIR/TARGET directory with a
>>> BUILDDIR/TARGET file (-f removes this, this is how the script knows
>>> to not try to re-do a build).

> At present both build and config logs, and the build directory get
> removed.  Only architecture output is left.

> I think this is ok since, unlike before, the command is restartable.
> If the build fails, just restart it with a more verbose option.

Just checking: if the build fails, the logs aren't removed, right?
That's what you seem to be saying above, and that seems to be what the
script does if I'm reading it correctly, but given that I'm not sure I
understand your last paragraph.

Certainly I think it would be bad if the logs were deleted if the
build fails, but I don't mind if they're deleted if the build
succeeds.

David Carlton
carlton@math.stanford.edu

Re: revamped gdb_mbuild.sh

[Andrew Cagney]

> On Wed, 27 Nov 2002 13:05:35 -0500, Andrew Cagney <ac131313@redhat.com> said:
> 
> 
>>>> The new script, once it has successfully configured, built, and run
>>>> a target, replaces the BUILDDIR/TARGET directory with a
>>>> BUILDDIR/TARGET file (-f removes this, this is how the script knows
>>>> to not try to re-do a build).
> 
> 
>> At present both build and config logs, and the build directory get
>> removed.  Only architecture output is left.
> 
> 
>> I think this is ok since, unlike before, the command is restartable.
>> If the build fails, just restart it with a more verbose option.
> 
> 
> Just checking: if the build fails, the logs aren't removed, right?
> That's what you seem to be saying above, and that seems to be what the
> script does if I'm reading it correctly, but given that I'm not sure I
> understand your last paragraph.

Yes.

If the build fails, nothing, for that build, is removed.  The directory 
is still there, the logs are still there.  You can even cd to the 
corresponding build directory and try finishing the build by hand.  The 
next time the script is run, it will pick up from where you left off.

> Certainly I think it would be bad if the logs were deleted if the
> build fails, but I don't mind if they're deleted if the build
> succeeds.

Andrew