On Wed, Mar 29, 2023 at 09:29:30PM -0500, Jacob Bachmeyer wrote:
> Do we need a direct configure test for "has Perl module"?
> AC_PERL_MODULE([Digest::SHA]) would need to execute `$PERL -e "require
> Digest::SHA"` and consider Digest::SHA available if that returns success.
> Using Perl's -M option works for most modules, but a few (such as
> Devel::Cover) produce effects beyond the perl process when import is called,
> so simply evaluating "require" is less likely to cause weirdness.
> (Theoretically, a module could do something when loaded with require, but
> those kinds of side effects are strongly discouraged. Devel::Cover creates
> a coverage database in the current directory when import is called, but does
> nothing when loaded with "require".)
It would likely be possible to implement whatever tests were desired.
For example, the Texinfo package has several occurences of checks for
Perl modules. Some of them occur at run-time, some at configure-time,
and some are fatal and some are non-fatal.
Here's an example of a configure check in configure.ac:
AC_MSG_CHECKING([Perl version for tests requiring unicode collation])
if $PERL -e "use 5.018_001; use Unicode::Collate" >/dev/null 2>&1; then
perl_unicode_collation_requirement='yes'
else
perl_unicode_collation_requirement='no'
fi
AC_MSG_RESULT($perl_unicode_collation_requirement)
PERL_UNICODE_COLLATE_OK=$perl_unicode_collation_requirement
AC_SUBST([PERL_UNICODE_COLLATE_OK])
An example of a run-time check (for the Archive::Zip module, in the
EPUB output code):
eval { require Archive::Zip; };
my $archive_zip_loading_error = $@;
