Is this a bug in GNU make?

[Brian Schrack]

In our working environment, files are frequently moved between computer
platforms using Linux and those running MS Windows.  If developers are not
careful to move text files using binary FTP, they can inject
carriage-returns before the newlines at the end of each line.  Processing
makefiles with these embedded carriage returns does not cause any problems
under most circumstances.

When performing an assignment which uses many continuation lines, it was
noticed that the makefile may fail to execute.  Details follow, but I have
two questions.

1) Why do these carriage returns sometimes but not always cause problems?
2) It is realized that running the dos2unix utility on the makefile would
remove the carriage returns and "cure" the problem.  Still most of the time
they do cause a problem.  Would this be considered a legitimate bug worth
filing a report on?  It is also true that breaking the assignment statement
into multiple smaller assignment statements will avoid the problem.
Changing the length of the filenames in the assignments can move the problem
to a different line or avoid the problem.


Details:

A simple makefile was created with the following form :

OBJS =  sub1.o \
          sub2.o \
          sub3.o \
          .
          .
          .
         sub299.o \
         sub300.o

mkinv: $(OBJS)
        cc -o mkinv.exe mkinv.c $(OBJS)


This makefile built the code without errors.  The file was converted to DOS
format using the utility unix2dos.  This injects carriage returns into the
file and simulates what would happen if the file was FTP transferred (using
ASCII mode) to a Windows machine.  When make was run on the altered file the
following error occurred:

Makefile:276: *** commands commence before first target.  Stop.

The error can be circumvented by modifying the makefile to use only the
first 275 “continued lines” for the first assignment statement and creating
a second assignment for the rest of the object files on  lines 276 through
300.

In looking at the current bug reports I notice Bug 1332 filed against Make,
which covers a similar issue "continued command lines are not passed to the
shell correctly".  Bug 1332 sheds some light on how the makefile is
interpreted.  In the comments within Bug 1332, reference is made to the
POSIX standard for make.  As make processes the assignment statement the
newlines(0x0A) preceded by a backslash (0x5C) are to be replaced along with
any leading white space on the next line by a single space.  A strict
interpretation of this procedure indicates that the common practice of
putting a space before the continuation backslash is unnecessary.  An
experiment was performed with the example makefile where this space was
removed resulting in the following format:

OBJS =  sub1.o\
          sub2.o\
          sub3.o\
          .
          .
          .
         sub299.o\
         sub300.o

mkinv: $(OBJS)
        cc -o mkinv.exe mkinv.c $(OBJS)

Makefiles with 1000 continued lines have been successfully executed (in DOS
format) when no space is included before the continuation backslash.

Versions:

GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for i386-redhat-linux-gnu

Red Hat Linux release 8.0 (Psyche)
Kernel 2.4.18-27.8.0 on an i686

The included achieve has the makefile in two forms, make.unix will build
code, make.dos will abort with the error.

mkinv.tar.gz
Description: GNU Zip compressed data