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.
<sigh>
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:
foo: foo.sh
(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 $@
endef
foo: foo.sh
$(fix_hashbang)
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?