Date: Wed, 16 Sep 1998 12:30:35 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: John Barber <john DOT andy DOT barber AT which DOT net>
cc: djgpp AT delorie DOT com
Subject: Re: gnu make 3.77 in djgpp binary distribution
In-Reply-To: <35FEDB9C.3665@which.net>
Message-ID: <Pine.SUN.3.91.980916123014.5874X-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Tue, 15 Sep 1998, John Barber wrote:

> .c.obj:
> 	cl $(IFLG) $<
> 
> where IFLG might be, say,
> 	-Zi -IG:\IPL\DEV\V32-044A\INCLUDE -Od -FRG:\IPL\DEV\SBR\
> 
> This doesn't work because the when the cl command is executed it
> receives a copy of the parameters with the back-slashes stripped out.

You need to double every literal backslash, like this:

  -IG:\\IPL\\DEV\\V32-044A\\INCLUDE

Make uses the backslash as an escape character for quoting special
characters like the blank and such, so it strips one level of
backslashes when it invokes programs.

> 	cl '$(IFLG) $<'
> 
> However, although this fixes the disappearing backslashes, I find the
> quotes themselves do not seem to be stripped from the parameters passed
> to the CL command - and CL does not like this one bit - it can live with
> quotes around the file-name of the file to be compiled, but not around
> the options.

This is clearly a bug in how CL processes its command-line arguments.
Try "$(IFLG)", with double quotes instead of apostrophes, it might
work better.

But doubling the backslashes is the best way, although it's ugly.

> Shouldn't the quotes be stripped by the shell-like processing in the
> system() library function?

`system' cannot strip the quotes because it doesn't know what
semantics they have in the program it invokes, and how does that
program treat the quotes it gets on the command line.  Since calling
a program via `system' is conceptually the same as doing that from the
DOS prompt, `system' passes the arguments verbatim, without stripping
the quotes, on the assumption that the called program will do the same
it does when invoked from the command line.  Any other behavior would
require `system' to have intimate knowledge of how every program it
invokes processes command-line arguments, which is impractical, as
each DOS program handles this in a subtly different way (it depends on
the compiler used to build it).