[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.


> 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

@echo one\\
@echo two

While defines like this one will behave without any surprises:

$(call foo,\

> 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)/' > $@

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.


Attachment: signature.asc
Description: Digital signature

reply via email to

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