Date: Sun, 23 Aug 1998 17:29:13 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: DJ Delorie <dj AT delorie DOT com>
cc: djgpp-workers AT delorie DOT com
Subject: Re: subtle make bugs
In-Reply-To: <199808210100.VAA22487@delorie.com>
Message-ID: <Pine.SUN.3.91.980823172854.1451j-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Thu, 20 Aug 1998, DJ Delorie wrote:

> This makefile fails, because it things that o: is a drive letter:
> 
> foo.o:/foo.c
> 
> This makefile fails because it doesn't think that o: is a drive letter:
> 
> foo.o : o:foo.c
> 
> The code that does this is apparently quite flawed (two similar cases
> in make's read.c):
> 
> 	  /* For MS-DOS, skip a "C:\...".  */
> 	  if (p != 0 && p[1] == '\\' && isalpha (p[-1]))
> 	    p = 0;

I assume you didn't use the latest Make 3.77, since that version
doesn't choke on the first example, only on the second.  Please try
Make 3.77.

The "d:foo" case was never supported by Make, AFAIK.

In fact, I doubt if it is even desirable to get it right.  The
drive-letter brain-damage is deeply in conflict with the Makefile
treatment of `:' as a separator.  The syntax of a valid Makefile lacks
rigorous definition.  Without such a definition, there are numerous
cases of what is and what isn't valid.  In addition, the Makefile
reader is hopelessly complicated to the degree that it is unreadable
and unmaintainable, and it just got even more so when v3.77 added
target-specific variables.

At least fully-qualified path names like d:/foo have a slash after the
colon to make the decision a bit more solid.  Without it, how will we
distinguish between your example and a static pattern rule, like this

  foo.o bar.o : %.o:foo.h

Is it so hard to say `o\:foo.c' instead, where a literal colon is
needed?  That's what a Unix user would do if they had a file name with
a literal colon.

> It needs to check that there's exactly one letter before the colon
> (beginning of line or preceeded by whitespace or non-file-name-char),
> it needs to allow both slash types, and it should allow any valid file
> character to follow the colon.

I can try to correct it if you really think the case of o:foo needs to
be supported, but ``valid file-name character'' is a Pandora box, as
you well know (in particular, it depends on LFN).  And the set of
separators of filenames in a Makefile is not well-defined.  Just a few
days after v3.77 was released, somebody reported that the case of
drive letters inside object libraries, like in "libfoo.a(d:/hack.o)",
was broken---because the parenthesis was one of the separators that
got forgotten.