On Fri, Sep 20, 2024 at 10:05:57PM +0300, Eli Zaretskii wrote:
> > The shell is not MSYS, it is:
> > shell: C:\cygwin\bin\bash.exe -eo pipefail -o igncr '{0}'
>
> Using the Cygwin tools to build MinGW ports is an uncharted territory
> for me: I never did that. MSYS was created (as a fork of Cygwin)
> precisely for this purpose: allow building MinGW ports using native
> Windows development tools (MinGW GCC and Binutils, native Windows
> Perl, etc.), and it includes several special tricks up its sleeve to
> that end. Examples include transparent conversion of /d/foo/bar file
> names to the Windows D:\foo\bar form, conversion of foo:bar:baz in
> PATH to Windows-style foo;bar;baz, EOL conversion where possible,
> conversion of /dev/null to NUL etc.
This last part about /dev/null probably explains why the test with
/dev/null does not fail in your setup, but fails in mingw on Cygwin.
> By contrast, Cygwin has a very different purpose.
>
> I think the correct way of building MinGW ports using Cygwin Bash and
> development tools is to use Cygwin-to-MinGW cross-compiler (I think
> the Cygwin project provides such cross-tools). Using native Windows
> executables (including MinGW GCC and Binutils, and other MinGW ports)
> is bound to cause problems such as this one.
That is what this CI platfrom does. But there is no Perl provided that
way.
> And I have no idea how to invoke Strawberry Perl from Cygwin in a way
> that will avoid these problems. I guess you could try removing CR
> characters, but that could bite you in some other cases, where a lone
> CR character is produced and is supposed to be kept. If you are
> lucky, this will never happen in Texinfo, but only if you are lucky.
Most of the tests that call texi2any directly pass, except one with
/dev/null and another with an issue with a mix of encodings, so it is
not that bad. I will continue to try to have the XS modules built, I am
curious to see if the tests still pass in that case.
--
Pat
