Re: pgsql: Reference test binary using TESTDIR in 001_libpq_pipeline.pl.

On 10/18/21 10:23 AM, Alvaro Herrera wrote:
> On 2021-Oct-17, Andrew Dunstan wrote:
>
>> +sub find_built_program
>> +{
>> + my $program = shift;
>> + my $path;
>> +
>> + if (defined $ENV{MSBUILDDIR})
>> + {
>> + # vcregress.pl sets MSBUILDDIR which is the root of all the build dirs
>> + my $wanted = sub { $_ eq "$program.exe" && $path = $File::Find::name;};
>> + File::Find::find($wanted,$ENV{MSBUILDDIR});
>> + }
> Hmm, it seems weird to have to use File::Find when we already know where
> the program is, right? I mean, per your previous patch, we know that
> the program is in $MSBUILDDIR/libpq_pipeline/libpq_pipeline.exe, so why
> don't we make this one be
>
> if (defined $ENV{MSBUILDDIR})
> {
> return $ENV{MSBUILDDIR} . "$program/$program.exe";
> }

Could do, but say the module had two programs? Mostly we don't do that
but Release/pg_isolation_regress has two executables, so it's more than
just theoretically possible.

File::Find on the build directory is likely to be fairly quick, but a
simpler way might be to use glob expansion:

maybe something like:

my @progs = glob("$ENV{MSBUILDDIR}/*/$program.exe");

plus some logic to disambiguate any duplicates.

>
> ?
>
> I noticed that drongo is still red, and reporting that no tests are
> being run. While this makes sense (because the list of tests is
> obtained by running libpq_pipeline), I am surprised that this isn't
> reported as such. I would have expected it to die with an error message
> starting with "oops: " ... did run_command() fail to return stderr?
>
> ... oh, run_command() seems a bit too optimistic: it doesn't check
> whether IPC::Run::run() failed. I think that's worth fixing
> independently.
>

Yeah.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com