On Wed, Aug 05, 2026 at 09:30:30PM +0200, Patrice Dumas wrote:
> Hello,
>
> I just did a commit to set TEXINFO_XS=omit for the pod2texi calls, such
> that they succeed even if the XS modules are not built already:
>
> https://cgit.git.savannah.gnu.org/cgit/texinfo.git/commit/?id=514b6b209e66ef1c1a6c90dd8ecbcca1388286ab
>
> Previously, the XS modules not loading would have lead to a silent use
> of pure Perl modules. Now it errors out since the changes in march. In
> a way this is a good thing, as an objective of the change was to always
> be certain of the state with respect to XS vs pure Perl.
>
> I am not sure that the current situation is the best, though, as now
> pod2texi will always use the pure Perl modules.
>
> Any remark, idea?
The subdirectories under the top level of the Texinfo package are built
in the order given in the top-level Makefile.am. There you can see that
Pod-Simple-Texinfo is listed after tta:
SUBDIRS += install-info js po po_document texindex tta Pod-Simple-Texinfo \
util doc man
So I would have expected the XS modules to be built. Under what conditions
are they not being built?
I remember there was unresolved business with the TEXINFO_XS variable.
As I remember, we were considering making the XS modules mandatory if it
was detected that they worked at configure-time, in order to reduce the
number of possible conditions the tests could run under. We were calling
the value for this "requiredifenabled".
However, for some reasons I did not understand at the time, using this
setting didn't work:
From: Patrice Dumas
Subject: Re: have TEXINFO_XS=required adapted to TEXINFO_XS_*=0 and disabled
XS
Date: Sun, 1 Feb 2026 16:08:43 +0100
> 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 propose to remove the reference to TEXINFO_XS=requiredifenabled in
INSTALL since it does not work as expected for now. Ok?
https://lists.gnu.org/archive/html/bug-texinfo/2026-02/msg00004.html
So I am unsure what the status of the TEXINFO_XS variable is now.
As you said, there were more changes in March, as seen in the following
ChangeLog entry:
2026-03-02 Patrice Dumas <[email protected]>
Finish TEXINFO_XS requiredifenabled implementation
* tta/perl/Texinfo/XSLoader.pm (init): now that all the modules that
need one have fallback, die if fallback is missing when it should be
present. Update comments.
* tta/perl/Texinfo/XSLoader.pm (override): die if overriding a
function failed and embedded_xs is set.
TEXINFO_XS was discussed on this mailing list in March (following the
Texinfo 7.3 release):
https://lists.gnu.org/archive/html/bug-texinfo/2026-03/msg00012.html
texinfo.texi does not mention requiredifenabled at all. There's also
nothing about TEXINFO_XS in NEWS. Does this need to be updated?
(I can do this if I understand what the possibilities are supposed to be.)
Texinfo/XSLoader.pm does not contain the string "requiredifenabled"
- is that because that behaviour is obtained by default if TEXINFO_XS
is not set to "omit"? Or are we using the value "default" instead of
"requiredifenabled"?
There have been quite a few commits touching Texinfo/XSLoader.pm, although
I can't see a ChangeLog entry or commit message referencing a change from
"requiredifenabled". However, the following commit appears to have
removed the text "requiredifenabled" from the file:
commit 24e67d5aa0ccf2b16f3e13aa2a55bc553037679e
Author: Patrice Dumas <[email protected]>
Date: 2026-03-07 13:23:37 +0100
* INSTALL, tta/perl/Texinfo/XSLoader.pm (_message, init, override):
make requiredifenabled the default for TEXINFO_XS. Remove
TEXINFO_XS warn, required and previous default possibilities.
e.g.:
@@ -252,13 +246,10 @@ sub init {
# Possible values for TEXINFO_XS environment variable:
#
+ # TEXINFO_XS=default # try xs, abort if enabled by TEXINFO_XS_*
+ # # and build options and not loaded
# TEXINFO_XS=omit # don't try loading xs at all
- # TEXINFO_XS=default # try xs, silent fallback
- # TEXINFO_XS=warn # try xs, warn on failure
- # TEXINFO_XS=required # try xs, abort if not loadable, no fallback
- # TEXINFO_XS=requiredifenabled # try xs, abort if enabled by TEXINFO_XS_*
- # # and not loadable
- # TEXINFO_XS=debug # try xs, voluminuous debugging, fallback
+ # TEXINFO_XS=debug # same as default, voluminuous debugging
#
# Other values are treated at the moment as 'default'.
@@ -274,7 +265,8 @@ sub init {
$TEXINFO_XS = '';
}
- if ($TEXINFO_XS eq 'requiredifenabled' and $disable_XS) {
+ if ($TEXINFO_XS ne 'omit' and $disable_XS) {
+ _debug("XS modules were disabled when Texinfo was built: $module");
$TEXINFO_XS = 'omit';
}
That appears to contradict the commit message that says "requiredifenabled"
is the default.
I'm happy for "default" to be used as the possible value instead of
"requiredifenabled".
There also appears to be an out-of-date comment in Texinfo/XSLoader.pm:
# Possible values for TEXINFO_XS environment variable:
#
# TEXINFO_XS=default # try xs, if enabled by TEXINFO_XS_*
# # and build options
# TEXINFO_XS=omit # don't try loading xs at all
# TEXINFO_XS=debug # same as default, voluminuous debugging
#
# Other values are treated at the moment as 'default'.
The out-of-date part is "if enabled by TEXINFO_XS_*" as these variables
(TEXINFO_XS_CONVERT etc.) aren't checked any more.
