On Mon, Jan 26, 2026 at 07:44:33PM +0000, Gavin Smith wrote: > On Mon, Jan 19, 2026 at 03:26:05PM +0100, [email protected] wrote: > > If it does not work out of the box, I do not think that we should invest > > much energy in making it work, this could be left to the next release. > > But we would change the wordings to make clear that the C implementation > > of texi2any is experimental. > > I do not understand the value to the user of ctexi2any, as it is.
Not much besides a choice of language for the main program. Note that texi2any.pl does not have additional value compared to ctexi2any either. Both are equivalent, so the one that is not used hasn't much value. I think that there is some value in building/testing the C implementation, as it makes it more easy to switch to that implementation as the main implementation, if we decide so, and users may be interested in that possibility. An option value of some sort (in economic terms). > It makes sense to me as part of a potential rewrite from texi2any from > Perl to C. We've discussed in the past the idea of progressing texi2any > from a Perl program to a Perl program that embeds C, to a C program that > embeds Perl, to a pure C program with optional Perl extensions. > (Whether this will ever actually happen is unknown.) I would already describe ctexi2any like that. But maybe you refer to the fact that indices sorting needs some Perl code and reproducible tests need the use of Unidecode to do the transliteration, in which case I agree. > This process > entails all the code being duplicated in both languages It is not this process that leads to most of the duplication, most of the duplication is already needed to have a good XS coverage. The actual duplications are texi2any.c, some code in convert/converter.c and convert/texinfo.c, the whole of convert/html_converter_api.c, convert/plaintexinfo_converter_api.c and convert/rawtext_converter_api.c. Then there are also additionally needed codes, namely the XSTexinfo/parser_document/ConfigXS.xs interface and everything related to Perl embedding, ie perl/load_txi_modules.pl, m4/txi_embedded_perl.m4, most of convert/call_conversion_perl.c, convert/call_embed_perl.c, some associated functions in Perl C codes and some code and functions here and there (for example in XSLoader). There are probably also some functions that are only used right now in relation to ctexi2any, but that would need to be implemented anyway if some other converters were ported to C, which I wouldn't count as being duplicated for ctexi2any. All in all, I do not think that there is that much additional code, but it is of course very subjective. > and complex > interactions between the two parts of the program, but in theory could > lead to a simple result at the end. In short, it's a bigger mess created > in the process of cleaning up a smaller mess. It is not clear to me what "complex interactions between the two parts of the program" actually mean. The code only needed by XS interfaces is, as far as I can tell, relatively well separated from the code needed for ctexi2any or the SWIG interface. It is not fully separated, there are some cases where some choices are made differently depending on Perl being embedded or not, but it is quite rare. There is some complexity, for sure, in ctexi2any related code, linked to Perl embedding, and also because there is one more interface gone through when embedded Perl is actually used. But this complexity is isolated from texi2any.pl. And ctexi2any is simpler than texi2any.pl when only C is used for HTML, as the complexity added by the XS interfaces is not present. > The mess is yet to be cleaned up. I do not really get it. I do not see anything obviously problematic with respect to some code needed for ctexi2any that would cause complexity for the code needed by texi2any.pl + XS. There is some added complexity for the "social" side of texi2any, as the ctexi2any stuff leads to annoucements, discussions, and queries (by myself) that are not needed for texi2any.pl and could annoy users and testers (and you ;-). > The use or non-use of XS modules in texi2any is already a significant > complication for users, and the ctexi2any option adds to this, > unnecessarily. Users can bump against it when reading INSTALL or the > output of "configure --help". We've already have confusion on this list > about the role of ctexi2any in the functioning of the texi2any program. That I can agree with. More flexibility/duplication can easily be a complication for users. There is a trade-off here that I cannot easily evaluate. > Text in INSTALL: > > * The `texi2any' (makeinfo) program is a Perl program in the default case. > > If you prefer a C implementation of the texi2any program, you can give > > the --enable-using-c-texi2any flag to `configure'. The C implementation > will > only be actually used if all the prerequisites are found, which includes > > a working iconv library, the possibility to embed a Perl interpreter > > and enabled Perl extension modules, known as XS modules. I agree that this text could be a distraction or a source of confusion. I have no problem with putting it somewhere else. > Why should users "prefer a C implementation"? Users shouldn't need to care > about texi2any internals or alternate implementations. The do not need to care, but they could care nonetheless. > As far as I remember, ctexi2any was not significantly faster than texi2any.pl > (or even slightly slower), so does not add value for the user. Last time I checked it was significantly faster, but only slightly faster, I agree that such a small difference does not add value. > The --enable-using-c-texi2any flag is an abuse of the configuration interface. > Node "Configuration" in the GNU Coding Standards: > > No ‘--enable’ option should *ever* cause one feature to replace > another. No ‘--enable’ option should ever substitute one useful > behavior for another useful behavior. The only proper use for > ‘--enable’ is for questions of whether to build part of the program > or exclude it. The "should ever substitute one useful behavior for another useful behavior" is not that clearly relevant here as there is no difference in features, the difference is the implementation. I agree, however, that it is not a "question of whether to build part of the program or exclude it". But I am also pretty sure that these rules are to be followed with reason, and the situation seems to me to be specific enough and not covered by the rule to warrant an exception. > ... > > You will note that the categories ‘--with-’ and ‘--enable-’ are > narrow: they *do not* provide a place for any sort of option you might > think of. That is deliberate. We want to limit the possible > configuration options in GNU software. We do not want GNU programs to > have idiosyncratic configuration options. I do not really understand what it adds to the previously said information and the "We do not want GNU programs to have idiosyncratic configuration options" is confusing to me as it could even go against using any --enable options, but I am probably misinterpreting what is said. > Similarly, in the GNU Autoconf manual: > > These options allow users to choose which optional features to build > and install. ‘--enable-FEATURE’ options should never make a feature > behave differently or cause one feature to replace another. Again I do not think that this applies to that --enable option, which does not leads to a different behaviour nor a feature replacement. > They should > only cause parts of the program to be built rather than left out. This applies, yes. > So if we want to provide some way to use ctexi2any as the texi2any > implementation, I'd suggest we find some other way of doing it than > a configure option. The only idea I have is to use an environment variable > instead. texi2any.pl could detect this environment variable and delegate > to ctexi2any. I do not find that idea very good, in my opinion, it would lead to unneeded complexity, possible confusion and would be overall less useful. I do not think that we should follow those rules to the point of choosing an inferior design. Overall, I am not convinced by the argumentation about --enable, because, as far as I can say (but I must say that those rules are not crystal clear to me), we use --enable for things other than "questions of whether to build part of the program or exclude it" for other options, for instance --enable-perl-xs, --enable-xs-perl-libintl, --enable-perl-install-mode. Yet, those seem useful and relevant, and I wouldn't like to have them removed for the sake of following that rule which, unless I missed something, is trying to avoid something else. > If we had an --enable-ctexi2any option this would control whether the > ctexi2any program is built and installed. It does not seem of much > interest to users to build the ctexi2any program in the build tree only > and not install it. I disagree on that. Having ctexi2any built and not installed can be useful for testing and being able to understand and compare designs. Whether this use is balanced by the risk of build failure, the increased build time and the waste of electricity and computer wear, I cannot tell, but it is definitely useful to have two implementations to compare. -- Pat
