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

On Wed, Jan 28, 2026 at 09:58:08AM +0100, Patrice Dumas wrote:
> 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.

Yes, it would be good to have less of this in source files:

>  "Texinfo::Convert::HTML::command_id"
>   => "Texinfo::Convert::ConvertXS::html_command_id",
>  "Texinfo::Convert::HTML::command_contents_target"
>   => "Texinfo::Convert::ConvertXS::html_command_contents_target",
>  "Texinfo::Convert::HTML::footnote_location_target"
>   => "Texinfo::Convert::ConvertXS::html_footnote_location_target",
>  "Texinfo::Convert::HTML::footnote_location_href"
>   => "Texinfo::Convert::ConvertXS::html_footnote_location_href",
>  "Texinfo::Convert::HTML::command_filename"
>   => "Texinfo::Convert::ConvertXS::html_command_filename",
>  "Texinfo::Convert::HTML::command_root_element_command"
>   => "Texinfo::Convert::ConvertXS::html_command_root_element_command",
>  "Texinfo::Convert::HTML::command_node"
>   => "Texinfo::Convert::ConvertXS::html_command_node",
>  "Texinfo::Convert::HTML::_internal_command_href"
>   => "Texinfo::Convert::ConvertXS::html_internal_command_href",
>  "Texinfo::Convert::HTML::command_contents_href"
>   => "Texinfo::Convert::ConvertXS::html_command_contents_href",
>  "Texinfo::Convert::HTML::_internal_command_text"
>   => "Texinfo::Convert::ConvertXS::html_internal_command_text",
>  "Texinfo::Convert::HTML::_internal_command_name"

(from HTML.pm.)  

> 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.

Good idea.

> 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.

Can you minimise what changes you make before the next release as it
may end up being a bigger change than you expected?