Murray Lang wrote:
Can I suggest that the svn:eol-style attribute be changed from “native”
to “CR” for ./configure and ./bootstrap.
Did you mean “LF”?
They aren’t going to be much
use for Windows builds anyway. It’s a trap for young players who svn at
work on their Windows machines (because their dialup at home is slow).
Bash barfs on unexpected “^M” (LF). It took me a while to nut that one
Whose bash? Cygwin? MSYS? Other? And which svn? (And I think you
out. Why am I not surprised that the bash authors haven’t bothered to
deal with CRLFs even after all this time?
I’ve wrestled with this a little bit. For Cygwin, it makes sense (and
very easy) to use a Cygwin version of svn that takes “native” to mean
Everything works fine if you do this. (If you need to use a Windows
you can do dos2unix on files that need it; more on this below.)
On MinGW/MSYS, it seems that you should be able to use a Windows binary
distribution of svn, which takes “native” to mean “CRLF”(^M^J). This
a problem with GNU Radio because the config/.m4 files use
eol-style=native, which adds a ^M to each line, which causes corruption
in the ./configure file produced by aclocal+autoconf. If I run just the
config/.m4 files through dos2unix, then everything works fine (apart
the harmless, seemingly random appearance of ^M characters in the output
from various programs and scripts).
Murray: Are you using Cygwin? Have you tried “dos2unix config/*.m4”
(before ./bootstrap)? Are there other files that cause problems?
As I see it, MSYS is stuck (perilously) on the fence between Linux and
Windows in that it is intended to work on Windows with Windows programs,
libraries, and (presumably) conventions, while using GNU (which seems to
mean “works like Unix”) tools built using (or forced by MSYS to use)
mode (treat ^M as a data character) file reads.
I think the “right” answer requires one or more of the following:
(a) The GNU folks need to define the input languages for the build tools
clearly distinguish between “newline” and “end-of-line separator” (if
and to carefully specify binary or text mode for all file opens. This
relieve the Cygwin and MSYS people of having to force everthing into
mode. (This may be an impossible task for technical reasons and assumes
have an interest in supporting Windows ports of their code.)
(b) The MSYS folks need to modify the build tools (as needed) to accept
input files (.m4, .ac, .in, etc.) with either LF or CRLF line
(This may also be impossible.)
As far as GNU Radio is concerned, my first thought it that makes sense
declare that all the Linux-style build files (.m4 for sure and possibly
and .in) use svn:eol-style=LF, assuming that there is no such thing as a
true Windows m4 or autoconf. On the other hand, it appears that
(http://gnuwin32.sourceforge.net/) might have “true” Windows versions of
these tools that would do the right thing with eol-style=native. (It
be interesting to see how far you could get with MinGW and GnuWin32
of MSYS; what shell would you use?)
My recommendations for GNU Radio would be:
(1) Better understand the problems Murray is having with ^Ms, to see if
there are problems in Cygwin or MinGW that I am not aware of.
(2) Are there any systems out there other than Windows that use anything
LF for line separator? If so, we should use eol-style=native for .m4
MinGW users can then do dos2unix config/.m4. If not, we could
the most people with the least inconvenience if we use eol-style=LF for
files. This would amount to declaring that the build tools are by
Linux tools and anyone who wants to try building with GnuWin32 can do
config/.m4. (As far as I can tell, the .m4 are the only ones that have
with MinGW/MSYS; I don’t know if there are problems with other files if
Windows svn is used with Cygwin.)
In general, I tend to lean towards the “purist” approach, but in the
maybe more than slightly) schizophrenic world of Cygwin and MSYS I’m not
sure what the “purist” approach is.
– Don W.