On Sun, Feb 01, 2026 at 04:08:43PM +0100, Patrice Dumas wrote:
> On Fri, Jan 30, 2026 at 10:24:25PM +0000, Gavin Smith wrote:
> > On Wed, Jan 28, 2026 at 09:58:08AM +0100, Patrice Dumas wrote:
> > > > My current idea with the requiredifenabled possibility is to use it such
> > > > that there is no need to report anything, if the state is no exactly the
> > > > expected state, there would be a failure.
> > >
> > > I failed to do that. For modules that are not replaced as a whole and
> > > have overriden functions, right now it is not easy to avoid functions to
> > > be overriden in advance. This could be changed, but there is also the
> > > possibility to replace whole modules that could be more relevant, as it
> > > would simplify XS loading and also make clearer which functions are
> > > overriden.
> >
> > I understand your idea for using the configure-time setting in the test
> > suite. This way the tests should be guaranteed to run according to what
> > configure found, which the user can check in config.log files or by seeing
> > the output of configure. It means the tests check that the XS modules load
> > and run as expected. (Printing the status of the XS code - or whether
> > ctexi2any is being used - when the test suite runs doesn't seem to be
> > easy to do.)
>
> I did what I could to be clearer and explain what still fails and why,
> with two FIXME.
>
> I think that we cannot do more for now, but if we manage to have
> fallback modules more generally, it could then work.
I still don't understand the problem with TEXINFO_XS_CONVERT=0 or
similar in combination with TEXINFO_XS=requiredifenabled.
If TEXINFO_XS_CONVERT=0, then Texinfo::XSLoader::override is not
run for certain functions, and so the TEXINFO_XS setting is ineffective.
>From Texinfo/Convert/HTML.pm:
if ($XS_convert) {
foreach my $sub (keys %XS_conversion_overrides) {
Texinfo::XSLoader::override ($sub, $XS_conversion_overrides{$sub});
}
It's also probable that the XS modules the functions come from aren't
loaded either, due to conditionals such as that in ConvertXS.pm:
BEGIN {
if (Texinfo::XSLoader::XS_convert_enabled()) {
$XS_package = Texinfo::XSLoader::init (
I haven't exhaustively checked through all the uses of
Texinfo::XSLoader::override so its possible that there are other uses
that are more problematic.
Texinfo/ParserNonXS.pm has unconditional overrides with Texinfo::MiscXS
subroutines, although doesn't appear to load the Texinfo::MiscXS module
anywhere. (If there's any problem here, it could be fixed by geting
rid of these XS overrides as they are not necessary in a "pure Perl"
module and they would probably only be used in rare circumstances.)
In fact, "use Texinfo::MiscXS;" only appears in Texinfo/Convert/Unicode.pm.
What would be the problem with setting TEXINFO_XS=requiredifenabled by
default for the test suite(s)?
I've tried configuring both with "--disable-perl-xs" and without,
and ran "make check" under tta/ after running
"export TEXINFO_XS=requiredifenabled", to success each time.
Even if TEXINFO_XS_CONVERT etc. cause a problem, these would rarely
be set except for testing during development.
You added the following comments (in Texinfo::XSLoader::init), but I
don't understand them. When would there be a problem with this part
of the code?
+ if (defined($additional_libraries) and $disable_C_libraries) {
+ # in that case, the loading of the module is expected to fail.
+ # FIXME expected failure when overriding a specific function
+ # if (!defined($fallback_module)) for modules without fallback.
+ # Cannot use _debug here...
+ #warn("No C libraries expected failure of loading $module_name\n");
+ } elsif (!defined($module_name) and !defined($fallback_module)) {
+ # An undefined module name should only happen based on the TEXINFO_XS_*
+ # environment variables values.
+ # FIXME expected failure for modules without fallback.
die "extension disabled, no required fallback module for $module\n";
}
}
