bug-make
[Top][All Lists]
Advanced

[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

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]