Message-ID: <35FEDB9C.3665@which.net> Date: Tue, 15 Sep 1998 22:26:52 +0100 From: John Barber Reply-To: john DOT andy DOT barber AT which DOT net MIME-Version: 1.0 To: djgpp AT delorie DOT com Subject: gnu make 3.77 in djgpp binary distribution Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Dear djgpp expert, ******************************************** SUMMARY: using gnu make 3.77 with the ordinary DOS COMMAND.COM shell, quotes may be necessary on a command line to stop the 'make' interfering with the parameters before they are passed to the command. However, the quotes themselves are not stripped before the parameters are passed to the command: I think they probably should be. ******************************************** DETAIL: I have a query about the gnu make 3.77 of which I have downloaded the binary from the djgpp collection and am attempting to use to drive the build of the DOS-platform version of a multi-platform product I am working on. I don't know whether what I am seeing is a bug or not - it relates to the handling of command line parameters passed to an invoked command, and I'm not very familiar with how this might be expected to work on a Unix system... Anyway, I am trying to tell MAKE to call the Microsoft C compiler to compile my C programs (I'm using this compiler because the product has been tested using it and is stable - I'm merely trying to tidy up the build procedure to make life easier for whoever may need to work on the package in the future. I find Microsoft NMAKE pretty useless, and PolyMake would be good but runs out of memory). I'm using the normal DOS COMMAND.COM shell. I have a rule like: .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. MAKE echoes the command line to the screen prior to invoking the command showing the back-slashes intact, but CL complains it can't find (e.g.) G:IPLDEVV32-044ASOURCEABC1.C (the dependencies also have paths with backslashes in.) I guess this is due to the fact that djgpp is trying to add value to the COMMAND.COM shell so that UNIX-aware users can use UNIX shell-like features they are used to - the readme file says this is done in the system() library function, I believe. I expected to be able to fix this problem simply by quoting the arguments, e.g.: cl '$(IFLG)' '$<' or 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. Shouldn't the quotes be stripped by the shell-like processing in the system() library function? (By the way, there are no quote characters internally within the options string to foul things up). I guess I could work around the problem by using forward slashes in my paths (I think CL is happy with these), but these paths come from environment variable which may be used in DOS batch files for ordinary DOS commands, so this would be inconvenient. I found I could work around the problem by using: echo $(shell cl $(IFLG) $<) which passes the parameters to CL just fine, but the output has its line-ends blanked out (as the documentation says it will), which is a nuisance. Interestingly, if I try to test various formats by replacing the CL command with 'echo', then the output looks as I thing it ought - the problem doesn't show up in this case. So what I'm doing for now is to put all the in the environment: export CL=$(IFLG) and then just cl '$<' (CL can pick up its options from the CL environment variable) However, I'd like to get to the bottom of the problem, in case it comes up again as I extend the scope of the makefile I am working on. Please excuse me if all the above is some kind of simple misunderstanding on my part - I'm dealing with a lot of stuff here that I'm not very familiar with. Any help or advice you are able to give, I will be most grateful for. Regards, John