On Thu, Mar 05, 2026 at 09:03:47AM +0100, Patrice Dumas wrote: > Hello, > > First, I finished replacing individual functions overriding by full > interface modules. There is one downsize, many Perl modules are now > divided in two files, but overall I think that the clarification of what > is and what is not in XS is worth it. Individual functions overriding > remain for MiscXS and ConfigXS. > > I think that the current situation regarding erroring out in case > some XS interfaces are not loaded in the default case, with TEXINFO_XS > unset is not the best. Indeed, for XS interfaces requiring the use of > the XS/C parser, it is erroneous to have only some XS interface files > loaded. The errors are diverse, some with visible messages > (document/converter not found), or segfaults, some with silent incorrect > output. None of those errors should be seen by users. > > I think that instead texi2any should abort with a message telling that > some XS interface object code could not be loaded. In practice, this > would mean making the TEXINFO_XS requiredifenabled behaviour the default > for XS interfaces requiring the use of the XS/C parser. The Paragraph > XS and Misc XS interfaces could still silently fail to be loaded in the > default case. > > What do you think?
I don't understand the dependencies among the XS modules well enough to make a definite recommendation. If I understand correctly, some of the XS modules depend on others being loaded correctly. You encountered one of the modules not being loaded and others breaking as a result. Is that because there was a bug in the parser module so it couldn't be loaded? Do we expect texi2any to be able to run if some random selection of XS modules couldn't be loaded? You mention the dependency on the XS/C parser but I expect there may be other dependencies between modules too. Would it be right to describe your recommendation as splitting the XS modules into two groups, "core" modules which would be loaded with with requiredifenabled, and other modules where fall-back to pure Perl doesn't cause any other modules to fail? Would it help to eliminate the possibility to set TEXINFO_XS_PARSER, TEXINFO_XS_STRUCTURE etc. separately at this stage (as you suggested in one of your recent emails)?
