On Fri, Jan 23, 2026 at 11:25:37PM +0100, Patrice Dumas wrote: > > 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. > > Ok, I'll use that.
I implemented something. > > 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. > > My current idea with the requiredifenabled possibility is to use it such > that there is no need to report anything, if the state is no exactly the > expected state, there would be a failure. I failed to do that. For modules that are not replaced as a whole and have overriden functions, right now it is not easy to avoid functions to be overriden in advance. This could be changed, but there is also the possibility to replace whole modules that could be more relevant, as it would simplify XS loading and also make clearer which functions are overriden. I propose to replace more systematically whole modules, and when there are common Perl parts either put it in the module doing the loading or in a separate module that would be loaded by the pure Perl module and be passed for the XS module as an XSLoader init $perl_extra_file. Note that it may be less flexible than overriding, in the (rare) case of overriden functions in a module depending on different conditions. If this is agreed that it is a good idea, I could start doing it a bit in this release for the modules that have a lot of overrides, but this is more for the next release. Any comment? -- Pat
