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