[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: define strangeness
From: |
Boris Kolpackov |
Subject: |
Re: define strangeness |
Date: |
Mon, 19 Apr 2004 18:21:18 -0500 |
User-agent: |
Mutt/1.5.4i |
I see you are running make time-slice ;-)
Paul D. Smith <address@hidden> 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