On Fri, Oct 09, 2026 at 10:46:07AM +0200, Patrice Dumas wrote: > On Thu, Oct 08, 2026 at 11:18:42PM +0100, Gavin Smith wrote: > > Is this a regression? In other words, should we expect Texinfo to build > > on this platform and for the tests to pass? > > As far as I know, this is not a regression, this is a new platform we had > not access to/no CI before. (Actually 3 new platforms, but the two > without shared libperl are less interesting). It was setup by Bruno > recently, as part of his work on the CI for many GNU projects. > > The errors could be common with Eli test platform.
It would be useful to have automatic builds on this CI system, then, presuming it is possible to get them to build successfully. > > It reminds me of the broken "Cygwin/MinGW" platform which I believe was > > also on the Github CI. I found some old emails about it. > > It has something in common, in that it is a native Windows platform. > But the similarity ends there, since the shell is completly different in > the new platform and also probably the Windows runtime is different. Eli > could correct me, but my understanding is that the new platforms are > more similar to the platform Eli tested previously, in particular the > platform he tested the previous release on. But it is not the same > either, Eli platform is, to my understanding, oldish on some aspects, > one being the MS-Windows runtime (it is not clear to me what are the > other differences, if any). As I remember there were (at least) two versions of the MinGW development tools, one with a website at mingw.org (which is no longer up), and another called mingw-w64, which is more actively developed. I remember that Eli has built with the mingw.org MinGW in the past, which may be part of what you are remembering. > The new platforms are supposed to be less broken than the "Cygwin/MinGW" > platform, and this is actually what I observe. > > > So I recommend checking exactly what this platform is before spending any > > more time on it and whether it is a valid platform to be supporting. Is > > it a MSYS2 build of texi2any (as Eli describes) or a MinGW build, for > > example? > > It is both, as far as I understand. Eli or Bruno could correct me, but > my understanding is that it is the modern way to build GNU/Posix > programs on native Windows environment. I know MSYS2 is described as a way of building native (a.k.a. MinGW) programs. So I would expect the programs produced (texi2any etc.) to be native Windows programs - producing text files with CRLF line ending, for example. > > We used not to depend on libperl - this is one of several issues from the > > last six months or so which I have planned to revisit. It was only > > required for embedding a Perl interpreter, which wasn't necessary for > > texi2any > > in any of the previously released versions of Texinfo. libperl was not > > installed on Debian-derived distributions, for example. > > We did not depend on libperl on platforms that do not need > -no-undefined. For platforms that need -no-undefined (MS-Windows), > libperl has always been required for XS code since you implemented the > parser in XS/C. > > A fully functional ctexi2any command requires embedding a Perl interpreter > and therefore requires libperl too. I think that ctexi2any is the > future, more than texi2any.pl is, so requiring libperl is going to be > more important than before on Unix platforms. We have all the time we > want, but in the future, it could be even be possible to remove > texi2any.pl and keep ctexi2any only. We have time, though, as we need > Perl and XS for the foreseable future mainly for tta/perl/t/*.t tests > anyway, so leaving texi2any.pl is not a big deal. OK, we can discuss this in the future if ctexi2any ever becomes the default. > We have removed some dependencies on Perl in the current release. > Some dependencies on Perl (for configure --enable-xs-perl-libintl, > language dependent collation, non functional iconv and disabled nls) > could probably be removed. However, the dependence on Perl or embedded > Perl is meant to remain, both for some formats (LaTeX, DocBook) > and for HTML customization. > > > Am I wrong in suspecting there may be the same problems with this > > MSYS2/MinGW setup as there were with the Cygwin/MinGW setup? > > Some problems may be similar, but many are not. The Cygwin/MinGW setup > has different issues regarding end of lines and is not well integrated, > it could not be used to build XS/C for instance. Conversly, the MSYS2/MinGW > can be used to build XS/C and ctexi2any, and this is probably the main > reason why there are new failures, it is because we test more > situations. The new platform, however, is much more similar to the > platform Eli used to test texi2any on, so the new failures could also be > on Eli test platform. I see, so the crashes could be inside the C code and Windows-specific. > The 2 MSYS2 mingw ucrt clang platforms do not have a shared libperl, > therefore it is not possible to build XS not ctexi2any. But the tests > pass on these platforms. > > -- > Pat
