%% Boris Kolpackov <[EMAIL PROTECTED]> writes: bk> No, I think it should handle newline-backslash sequence the same bk> way everywhere, including inside "define".
Hm. But, make already doesn't handle backslash/newline the same way everywhere; in command scripts the backslash/newline is not resolved during command read-in like it is for make constructs. Internally the script is stored with the backslash/newlines intact, just as it was read in. It's not until make is actually ready to run the rule that it removes them. One reason for this is so that when make prints the rule it's about to create the rule looks the way it looks in the makefile, rather than a big glob of code on a single line. If make removed the backslash newline from the define at make read-in time, then the output printed by make for that would lose all of its formatting. Also, I think it would change the meaning in some cases, because the backslash/newline expansion would be done _TWICE_, once when the define was parsed and then again when the command script was parsed. I agree that it is probably a very obscure define that would be impacted by this... about the only way I can think that it might have an impact is if someone had two backslashes at the end of a line: define weird echo foo\\ echo bar endef On the other subject, comments: I really think that this _would_ cause problems, and I don't think they're academic. Consider this define: define subst echo $> | sed 's/#foo#/$(FOO)/' > $@ endef for example. -- ------------------------------------------------------------------------------- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist _______________________________________________ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
