[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug #38795] texi2any makes CR in output when input is mixed CR-LF a
Re: [bug #38795] texi2any makes CR in output when input is mixed CR-LF and LF files
Fri, 17 May 2013 09:00:10 +0300
> From: address@hidden (Vincent Belaïche)
> Cc: Vincent Belaïche <address@hidden> ,
> Karl Berry <address@hidden> , address@hidden
> Date: Thu, 16 May 2013 22:27:27 +0200
> >Yes, MSYS programs always use binary I/O mode, because they simulate a
> >Posix environment. They are therefore inappropriate for installing
> >Info manuals on Windows, only for building those manuals.
> The question is then what the purpose is for an MSYS install-info. I was
> thinking that the purpose of MSYS at all was to install native windows
> application using the autoconf system and the mingw compile chain.
> If MSYS/install-info cannot be used to install manuals on Windows, then
> it is completely useless --- or I misunderstood again what MSYS is for.
I cannot think about a use case for the MSYS install-info that won't
be handled by a native port. Perhaps the reason for its existence is
that there wasn't a working native port of Texinfo to Windows for a
The rest of Texinfo does have its place: e.g., if you need to produce
printable versions of the manuals, for which you need to run Unix
shell scripts that are part of Texinfo.
> Also --- if it is essential to keep the binary mode for other reasons,
> like having gzipped binary manual at input --- it would be probably easy
> to make some work-around by assuming the potential presence of the CR
> before end-of-line when scanning for the DIRENTRY.
The native Windows port handles compressed files as well. It switches
to binary mode as appropriate.
> Would that native windows build of install-info be usable instead of the
> MSYS one as part of some MSYS automated build: most of the time
> probably, but there would be corner cases when the filename path is some
> MSYS specific path that is not understandable by Windows, e.g. some
> absolute path name, or some fstab wrapped path.
The problem with file names doesn't exist, as MSYS detects native
programs and modifies the file names to have the native Windows
format, before it passes them to those native programs. That's one of
the main reasons for MSYS's existence, one that distinguishes it from
> This means that this solution is ok only if you ``curse'' Windows users
> to call install-info manually :-(.
There's no curse. I'm using the native port in all the packages I
build with MSYS, and I have yet to see even a single problem.
> >> > /local/bin/autoreconf
> >> > Can't spawn "aclocal": No such file or directory at
> >> > /usr/autoconf/Autom4te/FileUtils.pm line 326.
> >> > autoreconf: failed to run aclocal: No such file or directory
> >This probably means you have an old version of autoconf.
> What I get is:
> /usr/local/bin>./autoreconf --version
> La syntaxe de la commande est incorrecte.
> autoreconf (GNU Autoconf) 2.69
Well, something is botched anyway. Suggest to update your autoconf
installation from the MinGW site.