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
[greg@p3 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
[greg@p3 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.
[greg@p3 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.
[greg@p3 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
_______________________________________________
Help-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/help-make
