[ntp:hackers] scripts that might be handy

Dave Hart davehart at gmail.com
Thu Sep 17 05:31:06 UTC 2009

On Thu, Sep 17, 2009 at 5:02 AM, Hal Murray <hmurray at megapathdsl.net> wrote:
> pogo:~murray/check-for-errors.sh greps for error patterns in A*/make.log
>  flock-build currently makes 20 different copies of make.log
>  Checking for errors by hand is likely to miss something due to operator
> fatigue.
>  This is my attempt to avoid that.

Thanks for sending this mail.  I've been using something similar for a
while.  The one I use is in pogo:~hart/bin/flock-scan - however it's a
noisy version that adds an extra step of tailing each log file, which
was once useful finding tweaks to the error checks.  That should
probably be a non-default option or removed from any committed
version.  Once I expect to be done with test builds in a repo, I use
pogo:~hart/bin/flock-clean to save the make.log files and then remove
all the A.* build directories.

You are welcome to giggle about flock-scan using tcsh for scripting :)
 Here are the actual error checks:

if ( { fgrep -H error: A.*/make.log } ) exit
if ( { fgrep -H "errors." A.*/make.log } ) exit
if ( { fgrep -H "*** Error" A.*/make.log } ) exit

> pogo:~murray/local-build.sh runs flock_build on just the local system.
>  Running flock-build on pogo takes a looooooong time, so I really want to
> catch all of the gross bugs before I get that far.  This lets you run the 4
> cases on your own system before wasting time on pogo.

pogo is amazingly antique in its CPU performance.  I have used a
similar script to build just the default configurationn (such as
A.pogo) but with flock-build compatible options.

> The genetic diversity of the flock is pretty small these days.  This also
> lets you run it on your local environment(s).
> Corrections/tweaks encouraged.  I'd be happy if somebody adopted them and
> merged them into the official recipe.
> I don't really understand the build/flock-build area.

One way you can get in trouble with flock-build is to use build
without any options, then use flock-build targetting that host, which
adds implied default configure options --enable-parse-clocks and
--enable-simulator on most hosts.  Both will use the same A.* build
directory name but with different configure options in effect.  It may
make sense to change flock-build to use a different A.* name including
a hyphen for the first of the four flavors, to leave the base A.*
directory without any hyphens to the administrator's use with build.

> It requires that you don't run configure in the directory you are working in,
> but that's the normal part of my development cycle.
> I assume there is another way, but I haven't figured it out yet.  Is there
> some simple idea I'm missing?

build and flock-build are meant to allow many targets to be built in
the same tree by keeping most build products in the per-target A.*
subdirectories, including configure's config.status and config.h.
Instead of invoking configure and make directly, use build or
flock-build or a similar script which will create the target A.*
subdirectory and provide the same configure switches flock-build would
use for the "base" or first of the four flavors.  The steps by hand
would be something like:

mkdir A.pogo
chdir A.pogo
../configure -C --enable-parse-clocks --enable-simulator

> Currently, I setup another directory (bk clone/pull, bootstrap), copy the
> patches over and run test-build.sh there.  (I suppose that could be a good
> staging area for bits to send to pogo, but I haven't gotten that organized
> yet.)

I'm pretty sure that's harder than it needs to be.

Dave Hart

More information about the hackers mailing list