I see you are running make time-slice ;-) Paul D. Smith <[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. Well, this makes sense and I think it should be left this way. > 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. Ok. > 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 I think that's exactly how it should be. Single backslash-newline should be stripped, double-backslash-newline should be change to single backslash-newline (escaping). This will allow one to write commands in define like this define @echo one\\ @echo two endef While defines like this one will behave without any surprises: define $(call foo,\ 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 I think such cases should be handled through escaping, e.g. define subst echo $> | sed 's/\#foo\#/$(FOO)/' > $@ endef To summarize, it seems to me that the way make handles defines now can lead to some subtle bugs that are really hard to find. On the other hand I don't think there is a way to fix this without shedding some backward-compatibility blood. -boris
signature.asc
Description: Digital signature
_______________________________________________ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
