Re: broken line continuation in DOS files

[Wolfgang Liebich]

Hi,

I'm having very similar problems.
I'm using a CM tool which "knows" about the difference in text files vs. binary 
files.
The Windows client extracts all text files with "\r\n" line endings. So it 
doesn't matter
which way I mount filesystems.
Automake produces a very similar output than the example below, i.e. the source 
files
are distributed all over the makefile.in, with the .PHONY target inbetween.
I'm using automake V1.4 (the version distributed with CYGWIN) and autoconf 
2.13, and
Cygwin V1.3.2-1 (that's the version of the installation tar file from which I 
installed
cygwin).
Is there any solution to make automake "DOS file compatible"? Esp. automake 
V1.4?

TIA,
Wolfgang Liebich

On Wed, Oct 17, 2001 at 07:47:27PM -0600, Eric Blake wrote:
> "Roth, Kevin P." wrote:
> > 
> > Eric:
> > 
> > Did you ever get any response on this issue? I'm using Cygwin 1.3.3 on a
> > W2K professional laptop and seeing the same thing with a different
> > package (cURL from curl.haxx.se).
> > 
> > I switched myself to binmode and it cleared right up; however I'd like
> > to think it could be made to work under textmode eventually...
> > 
> > Thanks,
> > --Kevin
> 
> No, I never heard more on this.  I'm wondering if bug-automake was the
> wrong place to report this issue.
> 
> At any rate, here's what I did to solve it more permanently on my
> machine. I have no idea if there is something more elegant, but this
> worked for me:
> 
> --- automake.in Mon Aug 27 07:21:28 2001
> +++ /usr/bin/automake   Mon Sep  3 22:47:24 2001
> @@ -6455,6 +6455,10 @@
> 
>      while ($_ = $am_file->getline)
>      {
> +        # canonicalize line endings to be just \n
> +        s/\r\n/\n/g;
> +        tr/\r/\n/;
> +
>         if (/$IGNORE_PATTERN/o)
>         {
>             # Merely delete comments beginning with two hashes.
> @@ -6498,6 +6502,9 @@
>      # FIXME: shouldn't use $_ in this loop; it is too big.
>      while ($_)
>      {
> +        # canonicalize line endings to be just \n
> +        s/\r\n/\n/g;
> +        tr/\r/\n/;
>         $_ .= "\n"
>             unless substr ($_, -1, 1) eq "\n";
> 
> > 
> > ----------------------
> > Original Message:
> > 
> > I checked out the jikes compiler via CVS
> > (:pserver:address@hidden:/usr/cvs/jikes, password anoncvs,
> > module jikes).  I'm using cygwin 1.3.2 on a Win98, with the drive
> > mounted in textmode, along with the latest cygwin release of automake,
> > unmodified:
> > 
> > $ automake --version
> > automake (GNU automake) 1.5
> > Written by Tom Tromey <address@hidden>.
> > [...]
> > 
> > The Makefile.am that comes with jikes has entries such as:
> > 
> > jikes_SOURCES = \
> > ast.cpp \
> > body.cpp \
> > ...
> > 
> > Since my drive is mounted textmode, the cvs checkout puts \\\r\n
> > sequences in Makefile.am.  However, automake reads the file in binary
> > mode, so it only recognizes \\\n as line-continuations.  As a result,
> > the generated Makefile.in ends up looking like:
> > 
> > jikes_SOURCES = \
> > 
> > ...
> > .PHONY: all ...
> > 
> > ast.cpp \
> > 
> > body.cpp \
> > ...
> > 
> > And this causes make to issue the famous "*** missing separator.  Stop."
> > error after configuration, since the makefile ends in a list of
> > filenames that do not form a rule.
> > 
> > I'm not sure where to make the patch, but it should be a simple matter
> > of telling automake to open Makefile.am in text mode, rather than binary
> > mode, or else treating \\\r, \\\r\n, and \\\n as equivalent line
> > continuations.  I was able to work around the bug locally by stripping
> > out all \r from Makefile.am.
> 
> -- 
> This signature intentionally left boring.
> 
> Eric Blake             address@hidden
>   BYU student, free software programmer