Re: XS module not loaded and erroring out in the default case

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