bug-m4
[Top][All Lists]
Advanced

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

Re: failed checks for m4 1.4.4


From: Eric Blake
Subject: Re: failed checks for m4 1.4.4
Date: Tue, 25 Apr 2006 01:55:08 +0000

> Hello,
> 
> I have appended the results of the command "env VERBOSE=1 make check" to this 
> message. It was executed under MinGW.
> Are any unkown issues shown?

Thanks for the report.

It looks like the bulk, if not all, failures are due to mingw's use of CRLF
line endings, whereas the test scripts expect LF line endings.  I am more
familiar with cygwin's approach to line endings than mingw's, but I know
that with cygwin, it is possible to choose whether files under a particular
mount point are interpreted as text or binary by default.  Forcing binary
rather than relying on the mount point would correct the test suite,
although I'm not quite sure of the ramifications to programs that use
m4 to generate text files and expect CRLF line endings.  However,
there was also a recent report that autoconf failed a number of tests
on cygwin text mounts, and I suspect that many of those failures
were due to m4's choice of line endings.  So I suspect that always
processing files in binary mode output is the best behavior for m4
in the long run (since with binary mode, if you really want CRLF output,
you can then feed m4 CRLF input; whereas with the current text mode,
you have no choice in the resulting line endings).

Be aware that m4 development has been slow lately, mainly because
it is waiting for libtool 2.0 to stabilize and be released.  A patch to
make m4 treat all files in binary mode would certainly be helpful, but
it might not be applied before m4 2.0 development begins again
in earnest.

-- 
Eric Blake




reply via email to

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