Re: have TEXINFO_XS=required adapted to TEXINFO_XS_*=0 and disabled XS

Gavin Smith <[email protected]>
Newsgroups gmane.comp.tex.texinfo.bugs
Message-ID <aXPAdny7FcTU-gbA@orangestar>
On Fri, Jan 23, 2026 at 12:48:38AM +0100, Patrice Dumas wrote:
> > If the behaviour you describe is useful, we could devise another value
> > for TEXINFO_XS than "required" to switch to such behaviour.
> 
> Maybe changing the semantics of 'required' is not a good idea.  I'll try
> to explain more clearly what is the behaviour I would like to have, then
> you can decide if it is right to change 'required' behaviour or add
> another possibility or change nothing.
> 
> To me the TEXINFO_XS setting, the TEXINFO_XS_* variables setting, and
> whether XS is disabled or not are easy to know and in often under the
> user control.  Therefore it is does not seems very interesting to me to
> diagnose situations where there are inconsistencies among those
> variables.  Conversely, given TEXINFO_XS_* variables values, whether all
> the XS modules and functions that could be loaded are actually loaded is
> an interesting information, and is not an information that is easy to
> get.  One have to set TEXINFO_XS=debug, look at the result, and analyse
> it to get to the conclusion that an XS module that could be loaded is
> loaded or not.
> 
> What I would like to add is the possibility to set TEXINFO_XS to some
> value that leads to a failure if some XS modules that could be loaded
> given the values of TEXINFO_XS_* are not loaded.  TEXINFO_XS=required as
> it is now cannot play that role, because if a XS modules is not loaded
> because it is implied by the TEXINFO_XS_* value the command fails.

That all sounds fine but I would like to keep "required" as it is.  It's
fine to add another option.  I suggest "requiredifenabled".  The "enabled"
part could refer to the result of running 'configure' or the TEXINFO_XS_*
variables.

I've got in mind to think about how to report status of XS code better
for the test suite, but haven't been able to get to this yet.

> For example, with TEXINFO_XS_PARSER=0, there is no possibility to
> enforce that all the MiscXS modules are loaded (no other XS module can
> be loaded since the Parser is the pure Perl parser).  Since the other XS
> modules cannot be loaded, setting TEXINFO_XS=required leads to a failure
> because the Parser pure Perl module is loaded, not the XS module.
> 
> Is it clearer?  Does it seems interesting?  If yes, should 'required'
> meaning be changed, another TEXINFO_XS possibility be added or something
> else?
> 
> -- 
> Pat
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.