Hi,
On 2021-10-14 18:08:58 -0400, Tom Lane wrote:
> Andres Freund <and...@anarazel.de> writes:
> > Hm, so it seems we should make the test separately verify that perl
> > -M{Opcode,
> > ExtUtils::Embed, ExtUtils::ParseXS} doesn't fail, so that we can fail perl
> > detection with a useful message?
>
> Our existing policy is that we should check this at configure time,
> not later.
Yea, I was thinking of configure (and meson's equivalent) as well.
> Since plperl won't work at all without Opcode, it seems
> appropriate to add a check there if you say --with-perl. I wasn't
> aware that Red Hat had unbundled that from the minimal perl
> installation :-(.
>
> OTOH, if they've not unbundled ExtUtils::Embed or ExtUtils::ParseXS,
> I doubt it's worth the configure cycles to check for those separately.
On debian the perl binary, with a sparse set of modules is in
perl-base. ExtUtils::Embed and ExtUtils::ParseXS are in
perl-modules-x.yy. Whereas Opcode is in libperlx.yy. But libperlx.yy depends
on perl-modules-x.yy so I guess an Opcode.pm check would suffice.
Seems we can just check all of them at once with with something like
perl -MOpcode -MExtUtils::Embed -MExtUtils::ParseXSNotAvailable -e ''
Can't locate ExtUtils/ParseXSNotAvailable.pm in @INC (you may need to install
the ExtUtils::ParseXS3 module) (@INC contains:
/home/andres/bin/perl5/lib/perl5/x86_64-linux-gnu-thread-multi
/home/andres/bin/perl5/lib/perl5 /etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1
/usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/share/perl5
/usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.32
/usr/share/perl/5.32 /usr/local/lib/site_perl).
Greetings,
Andres Freund
