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

Reply via email to