[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug

From: Yuri Shtil
Subject: Re: Bug
Date: Sat, 22 Aug 2009 20:22:29 -0700
User-agent: Thunderbird (Windows/20090812)

John Calcote wrote:
On 8/22/2009 5:04 PM, Philip Guenther wrote:
On Sat, Aug 22, 2009 at 2:38 PM, John Calcote<address@hidden>  wrote:
You have to admit that Yuri has a valid point here. 99.9999 percent of all
developers know that a hash mark starts a comment, wherein the following
text is ignored until the next newline. .0001 percent of developers have
read the GNU make manual /closely enough/ to understand that under certain
conditions, a hash mark doesn't necessarily mean that the following text is
ignored till the next newline.

So people don't read the docs.  The problem is that the current
behavior was chosen because it matches the expectations of other
people, particularly the expectation that 'define' be usable for
defining command sequences.  Consider this:

         (echo '#!$(SHELL)'; cat $<)>$@
         chmod 755 $@

That works just fine as a rule for fixing up the leading #! line in a
shell script.  Is anyone surprised that it _doesn't_ give a syntax
error by passing the shell
    (echo '

Okay, how about this?

define fix_hashbang
(echo '#!$(SHELL)'; cat $<)>$@
chmod 755 $@


Does the current behavior make sense now?  The backwards rule is the
one that has '#' starting a comment in normal variable=value
definitions, but that can't be fixed because it's been like that since
'make' was first written back at Bell labs.

So, make uses different rules for different contexts and people don't
read the docs and can trip on those differences.  Great: what's your
suggestion for making this better?

Philip Guenther

P.S: if your post was actually less about make and more how about the
phrasing of my initial post downplayed the issue, well, that's just
how I use the socratic method, trying to elicit a recognition of the
ways in which something that was surprising from one view is less
surprising when considered from a different view by exploring 'nearby'
examples.  Perhaps I should switch to the direct "no, that's not a bug
because it permits<whatever>; go read the docs" style?

LOL. :-) Okay, you got me. My point was, in fact, about the nature of your response. And btw, thanks for the make lesson.

I did not mean to start a philosophical argument. I guess the catch is in the following in the manual:
Within a |define| directive, comments are not ignored during the definition of the variable, but rather kept intact in the value of the variable. When the variable is expanded they will either be treated as |make| comments or as command script text, depending on the context in which the variable is evaluated.

The example Philip gave:

(echo '#!$(SHELL)'; cat $<)>$@

make a lot of sense, however in my example the comment starts in the beginning 
of the line and the line no matter when evaluated will be thrown away.
However if the intent is to preserve side effects, then it will work.
Intuitively, if I put a hash inside a shell call (or other construct), I would 
expect it to NOT invalidate the rest of the line. I would escape the hash in 
this case as the manual recommends.
But a hash sign in the beginning of the line would probably mean I don't want 
the line to matter.

I learned my lesson: RTFM.




reply via email to

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