On Mon, 12 Feb 2001, Craig A. Berry wrote:
> The patch attached here attempts to make configure.com run nicely in
> batch mode. It addresses the following problems I encountered when I
> tried that:
>
> 1.) I don't know if there is any perfect way to get the name of a
> batch job's log file, but what we had was guaranteed to return an
> empty string, which it was then using to open a new version of the
> file. What I replaced it with worked fine in my tests.
>
> 2.) A batch job seems to have about half a dozen files open at the
> beginning that it doesn't have open at the end. I don't know if
> there are channels open on the queue or queue manager that get
> deassigned at some point or what, but the attempt to keep track of
> what the process has open was generating a false positive when
> checking for leftover open files. In any case the check for
> leaking filehandles is only valid if you have more files open than
> you started with, so I've changed .NE. to .GT. in these tests.
>
> 3.) Executing STOP in a command procedure bounces you back to command
> level 0, thus stopping any other procedure from which configure.com
> might be run. This is unlikely to be a problem interactively, but
> quite likely to be a problem in batch if you do a configure, build, and
> install all from one procedure.
I see that you have only removed the last stop - which should not have
been there I guess. The other STOP statements are true error handling
exits and are there to help you stop a bad build from proceeding
unattended (e.g. in a batch queue).
> I'd appreciate testing and/or comments before sending this along to p5p.
It looks good to me. We seem to have a few back patches for configure.com
piling up: Charles Lane's fix for the PERL_REVISION='' thing (despite my
objection that munchconfig ought to be made more flexible: I've not
implemented something that works yet), plus the extra_pods.com and ccname
work that I wanted to get in, plus your request for cf_by and perladmin
overridability, plus the DOWN_LOGICAL_NAME_NOT_LIKELY test workaround. Are
these getting into the vmsperl p4 repository? They weren't handed to p5p.
Peter Prymmer
