Re: make: # in quotes is still treated as comment character

[John Alvord]

I've used a simple circumvention for years.

_POUND = \#

and then use $(_POUND) in the command rules. which are interpreted by
shells after substitution.

Of course not using # in filenames helps!!

john alvord

On Fri, 12 Apr 2002 19:46:22 -0500, Manoj Srivastava
<address@hidden> wrote:

>Hi,
>
>        [Please retain the CC to address@hidden and
>         address@hidden so that the Debian Bug
>         Tracking system can record your input] 
>
>
>       The following problems were reported by debian developers. I
> am not sure they are related, but they seem to deal with quoting of
> targets in make rules. I am not sure whether these are bugs, but
> there does seem to be an inconsistency somewhere.
>
>       manoj
>
>######################################################################
>Make apparently does not escape # characters in quotes, so that the target
>
>foo: $(shell grep -v "^#" gj-files)
>
>will yield the error message
>Makefile:1: *** unterminated call to function `shell': missing `)'.  Stop.
>
>However, this works fine in commands, and backslash-escaping works, so that
>the following fragment works fine:
>
>foo: gj-files $(shell grep -v ^\# gj-files)
>       cat $(shell grep -v "^#" gj-files) > $@
>
>This bug affects variable setting, as well, so that
>
>VAR=$(shell grep -v "^#" gj-files)
>
>gives an error when $(VAR) is referenced, even though manually expanding
>the command would work fine; that is
>       echo $(VAR)
>gives and error even though
>        echo $(shell grep -v "^#" gj-files)
>works fine.
>
>Again, using backslash escaping is a possible workaround for this.
>
>I would claim that the makefile lexer should be string-aware, and not
>process # characters as comments inside quoted strings.  I'm not
>positive this is a bug, but it seems like one to me.
>
>######################################################################
>
>  If a filename contains a space or a dollar, make/its default rules
>fail to escape or quote the name correctly when invoking the compiler. 
>
>  Here's how to reproduce this problem:
>cat >Makefile <<__EOF__
>all: pound dollar space
>       @echo "It all works!"
>
>pound: pound\#file.o
>       @echo "Pounds work"
>
>dollar: dollar$$file.o
>       @echo "Dollars work"
>
>space: space\ file.o
>       @echo "Spaces work"
>
>clean:
>       @rm *.o
>__EOF__
>cat /dev/null >'pound#file.c'
>cat /dev/null >'dollar$file.c'
>cat /dev/null >'space file.c'
>make -k
>cc    -c -o pound#file.o pound#file.c
>Pounds work
>cc    -c -o dollar$file.o dollar$file.c
>cc: dollar.c: No such file or directory
>cc: No input files
>make: *** [dollar$file.o] Error 1
>cc    -c -o space file.o space file.c
>cc: cannot specify -o with -c or -S and multiple compilations
>make: *** [space file.o] Error 1
>make: Target `all' not remade because of errors.
>
>(beware the tabs of course ;-))
>
>Things to note:
> * 'cc dollar$file.o', $file is not set so cc tries to read 'dollar.c'
>and fails. The $ should have been escaped but there is no way to escape
>it in the Makefile that will work.
>
> * 'cc space file.c', same thing, the space is not escaped so cc tries
>to read 'space.c' and fails. Adding an additional \ in the Makefile
>results in make complaining it cannot find 'space\ file.c'. 
>
> * Putting single or double quotes around the troublesome filenames does
>not work: make takes them to be part of the file name.
>
> * Escaping the pound sign works. I'm not sure how make invokes cc (via
>fork()/exec(), system(), sh?), but it seems no shell is
>involved since '#' would make the start of the comments.
>
> * '$' behaves strangely. It is interpreted by make before
>anything else, including '\'. So '\$' does not work and one must use
>'$$' (which is documented). This is a bit confusing. Would it break many
>makefiles if '\' were interpreted first so that '\$' is equivalent to
>'$$'?
>
> * Workaround: adding rules like the one below solve this problem:
>.c.o:
>       cc -c -o '$*.o' '$<'
>
> * Optional question: how would one write a generic command to link a
>bunch of object files containing spaces together? It seems "'$^'" would
>not work.