[ntp:hackers] scripts that might be handy
stenn at ntp.org
Thu Sep 17 05:32:55 UTC 2009
> 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
> This is my attempt to avoid that.
> 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.
Yeah, pogo is not the fastest...
We're working on getting more machines at ISC - we currently have
FreeBSD, Debian, and OpenSolaris boxes.
> 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.
> 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.
Dave Hart has done some work on these scripts.
'build' does a single build on the current machine.
flock-build produces a variety of builds on each machine listed in the
LIST environment variable.
Due to the way 'configure' works, if you run it in the top-level
directory you can only build for 1 architecture. If you run it in the
top-level directory you cannot do a subdir build without a "make clean"
step, as a build in the top-level will generate .h files that will be
found and (incorrectly used) by a subdir build.
If you want to build anything other than a single instance, you can use
top-level builds. Otherwise you will need to use a subdir build.
Note that the flock-build script will build "normally", and also without
debugging, and without SSL, and I forget what else.
If you are making changes to the code we recommend doing a complete
flock-build because that will catch errors like the recent 'debug build'
problem with a patch.
> I assume there is another way, but I haven't figured it out yet. Is there
> some simple idea I'm missing?
Did the above help?
> 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
MY brain is tired after a long day - perhaps others have more ideas.
More information about the hackers