On Sat, Oct 26, 2024 at 10:43:54AM +0100, Gavin Smith wrote: > Thanks, this makes sense to me. As far as I understand, this "mingw" is > not a valid architecture worth supporting. It is said to be mingw but > some cygwin programs are in use:
Indeed, it is not mingw built on mingw, it is mingw built on cygwin. > The question is, is it mingw (native Windows programs), or Cygwin? The result is mingw, ie a native Windows program. The build platform is Cygwin. > If the answer is neither, but some mixture of the two, then my working > assumption is that it is a bogus setup not worth spending time on. It is quite broken, as it was already discussed in length before, but not so broken either. The test that fail do not show anything really problematic for real life use, otherwise said, native Perl run texi2any on cygwin is way more likely to produce a correct output than the not. > I feel it would be a mistake to hide these test failures, as it could > give someone false confidence that what they were doing was valid. I can't see what is fundamentally invalid in trying to build mingw on cygwin. These are not mistakes, but incompatibility between the native commands used at runtime for the tests and the cygwin shell and tools. So, the point is not whether the platform is good or not, the real issue is whether the added complexity in the tests balances with the interest of making easier to determine when a new test fail or a test that failed do not fail anymore for that platform. Also note that the real issues with that platform are not actually the failing tests, but the fact that prove cannot be used and pod2texi tests are therefore not run, that it is not possible to install the modules for the tp/*.t tests, that xsubpp cannot be run, and therefore there is no XS, and maybe there is no ncurses, so no Info reader. -- Pat
