[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: texinfo-5.9.90 pretest available

From: Eli Zaretskii
Subject: Re: texinfo-5.9.90 pretest available
Date: Sat, 28 Feb 2015 13:53:21 +0200

> Date: Sat, 28 Feb 2015 10:55:45 +0100
> From: Patrice Dumas <address@hidden>
> Cc: Karl Berry <address@hidden>, address@hidden
> 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.

Yes, it is.

> > 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?

It's a missing feature in MSYS, yes.  But I don't hold my breath to it
being fixed.

> 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.

Yes, I agree.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]