On Thu, Jan 22, 2026 at 06:22:44PM +0000, Gavin Smith wrote: > On Wed, Jan 21, 2026 at 11:40:08PM +0100, Patrice Dumas wrote: > > Hello, > > > > If TEXINFO_XS_PARSER=0, and TEXINFO_XS=required, there is a fatal error > > set the TEXINFO_XS environment variable to 'omit' to use the pure Perl > > modules > > because the Parser is non XS. > > > > I think that it could be possible to make TEXINFO_XS=required more > > useful, by using the following rule: > > > > With TEXINFO_XS=required, if TEXINFO_XS_PARSER=0, or > > TEXINFO_XS_STRUCTURE=0, or TEXINFO_XS_CONVERT=0 and the name of the > > loaded file is undef (because it has been detected in the code calling > > XSLoader that the user does not want an XS module), and there is a > > fallback module, let it be. Still die if a module that does not have a > > fallback (with overrides only) does not load, or a function override > > fails. > > I don't understand this. The point of TEXINFO_XS=required is to ensure > that the XS code is run. This is used for testing the XS code and that it > runs correctly. What would be the point of allowing the XS code not to run? > > That would mean that we could be trying to test the XS code, set > TEXINFO_XS=required, and get an apparent success, and yet it was the pure > Perl code that was run instead. > > The current behaviour of TEXINFO_XS=required is quite easy to understand > but now you are proposing that its behaviour depends on the value of > several other environment variables as well as the results of > configure-time checks. > > 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. 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
