Re: texinfo-5.9.90 pretest available

[Patrice Dumas]

On Fri, Feb 27, 2015 at 09:27:41AM +0200, Eli Zaretskii wrote:
> 
> revert them.  IOW, this is unreliable.  So we provide Windows batch
> files to DTRT, each one of which basically invokes Perl on its
> namesake Perl script, e.g., there's texi2any.bat that invokes
> "perl texi2any".

It seems to me that 
 util/makeinfo.bat
is exactly such a file.

> The problem happens when a test invokes just "../texi2any" or some
> such, 

texi2any has the "/usr/bin/env foo" substituted, so invoking 
../texi2any should work ok.  However, texi2any.pl has "/usr/bin/env
foo".

> because MSYS doesn't seem to support "/usr/bin/env foo" kind of
> shebang.  That's all there is to it: a test fails because such
> invocation of a Perl script will not work on MSYS.

Isn't that a MSYS bug that should be fixed in MSYS anyway?

> That is why I think the issue can be easily fixed (provided that
> there's an agreement to fix it) -- it is limited to how the script is
> invoked by a test script.  There are no other issues with this related
> to the Windows port that we didn't already solve.

I also think that it is necessary not to invoke texi2any.pl in
make/build/test script directly, because if we do that, even if
"/usr/bin/env foo" works as it should be, it means that the perl used in
that invocation is the one found by env, and not the $PERL detected by
configure or set by the user with $PERL environnement variable set when
running ./configure.  It could even be that there is no perl at all on
the path, in that case, the build and tests should proceed anyway.  So
we should indeed always invoke texi2any.pl with the $PERL detected by
./configure.  This means that shells/environements that do not process
correctly "/usr/bin/env foo" should be handled as a co-benefit.

-- 
Pat