On Thu, Aug 06, 2026 at 04:47:23PM +0100, Gavin Smith wrote: > 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 think that they are not built because it is a "make dist". I should probably have been clearer that I did something like make maintainer-clean ./configure make dist > I remember there was unresolved business with the TEXINFO_XS variable. I think that it is resolved. (Except for this new issue I describe above that popped up recently). > 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: > > 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. I do not remember the details, but I remember that I fixed that after the release. This is fixed now, all the modules depending on the libraries have a fallback. > 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 Indeed, at that time all the code was fixed and at the end of the thread we agreed that requiredifenabled would be the default, that's why it is not mentioned anywhere. > 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.) I do not think that the NEWS should be updated, the new behaviour is not different enough from the old one, it is more strict, but we never set expectations on the strictness of XS modules loading. The information in the manual and in INSTALL are up to date. > 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"? This is the reason, yes. > 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: Indeed, that is the commit that removes "requiredifenabled" because the corresponding behaviour becomes the default. > 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. he intent of the commit and of the message is that making "requiredifenabled" the default means doing what "requiredifenabled" did previously for any value except for "omit" (and "debug"). This means that there is noneed for the comparison to "requiredifenabled" anymore. But it is possible that the commit message does not mean that. > I'm happy for "default" to be used as the possible value instead of > "requiredifenabled". Actually any value that is not omit nor debug can be used. We document "default" in the manual, but it is in order to have a value shown. > 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. You are right, I'll remove that. -- Pat
