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
mean
“^M”(CR).)
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
is
very easy) to use a Cygwin version of svn that takes “native” to mean
“LF”.
Everything works fine if you do this. (If you need to use a Windows
svn,
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
causes
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
from
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)
binary
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
to
clearly distinguish between “newline” and “end-of-line separator” (if
necessary),
and to carefully specify binary or text mode for all file opens. This
would
relieve the Cygwin and MSYS people of having to force everthing into
binary
mode. (This may be an impossible task for technical reasons and assumes
they
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
separators.
(This may also be impossible.)
As far as GNU Radio is concerned, my first thought it that makes sense
to
declare that all the Linux-style build files (.m4 for sure and possibly
.ac
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
GnuWin32
(http://gnuwin32.sourceforge.net/) might have “true” Windows versions of
these tools that would do the right thing with eol-style=native. (It
would
be interesting to see how far you could get with MinGW and GnuWin32
instead
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
but
LF for line separator? If so, we should use eol-style=native for .m4
files;
MinGW users can then do dos2unix config/.m4. If not, we could
accommodate
the most people with the least inconvenience if we use eol-style=LF for
.m4
files. This would amount to declaring that the build tools are by
definition
Linux tools and anyone who wants to try building with GnuWin32 can do
unix2dos
config/.m4. (As far as I can tell, the .m4 are the only ones that have
a
problem
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
slightly (ok,
maybe more than slightly) schizophrenic world of Cygwin and MSYS I’m not
sure what the “purist” approach is.
– Don W.