Re: inconsistency of 'emptiness'?

[gk]

At 05:23 PM 1/28/2003 +0100, Der Herr Hofrat wrote:
> I still think it is a shell problem not make


Here is some more insight.
Apparently what is happening is this:
1. the shell interprets the command-line as it always does
2. make EVALUATES substrings after the equals sign IN THE SHELL AGAIN, 
before making the makefile variable assignment.

This is inconsistent with both environmental and makefile variables:
* environmental variables don't require 'double-escaping' like command-line 
vars do
* makefile variables don't accept backslash as an escape character for 
leading-space, as command-line vars do.

Here's another example with slightly revised makefile.
# Makefile
.PHONY: test
# test if FOO is empty
ifeq ($(FOO),)
result:=FOO is empty
else
result:=FOO is not empty: FOO=$(FOO)
endif

test:
        @echo origin of FOO is: $(origin FOO)
        @echo $(result)
#eof
address@hidden junk]$ make FOO=' hi' test
origin of FOO is: command line
FOO is not empty: FOO=hi

COMMENT: make lost the space it was handed by the shell

address@hidden junk]$ make FOO='\ hi' test
origin of FOO is: command line
FOO is not empty: FOO= hi

COMMENT: make sees the space this time, seemingly because it evaluates what 
the shell handed it, a second time.

address@hidden junk]$ echo '\ '
\

COMMENT: just to illustrate what the shell does and what it doesn't do: it 
hands make a literal backslash, if one is quoted on the command line.

address@hidden junk]$ make FOO='" hi"'
origin of FOO is: command line
FOO is not empty: FOO= hi

COMMENT: just to illustrate that it doesn't matter how you 'double-escape' 
things: shell hands make a string surrounded by literal double-quotes and 
makes seems to evaluate it again so you preserve the leading space.


I think this behavior should at least be documented, if not changed.


- Greg Keraunen
http://www.xmake.org
http://www.xmlmake.com