On Fri, Mar 06, 2026 at 10:00:44PM +0000, Gavin Smith wrote: > 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?
It could happen during development. But it can also be understood by looking at the code. To make sure, I also tested by artificially making a module loading fail to be sure that my analysis was right. > 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. What I meant by the dependency on the XS/C parser is not that the modules with break if the Parser is not loaded (which is true by the way). What I wanted to do is characterize a group of modules that fail if only some modules are loaded (except if done in a special way, as is done with TEXINFO_XS_*, which makes sure that none of the modules used after a given step are loaded). Maybe to explain it more clearly, I should have described this category of modules as all the modules whose XS interfaces set or use the Texinfo tree elements. So, Parser, Document, Structuring, Transformations, ManipulateTree, Convert::Converter, Convert::Text, Convert::HTML and Convert::Texinfo. (In my tests, OutputUnits and Indices not loading do not trigger any error, but I think that we should not make an exception, for simplicity.) I thought that in XSLoader.pm, these modules could be considered to be the modules needing additional libraries. > 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? Yes. > 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)? I am not sure. My feeling is that it would make the requirement to load all modules together more stringent. -- Pat
