On Thu, 2013-09-05 at 11:43 +0100, Tim Murphy wrote:
> The detection also appears to only work if the statement has a syntax
> error in it.
Correct. If make can understand what the line is (it's a valid makefile
syntax), then why would it assume that the programmer may have meant
something different than what was typed?
That is a road leading directly to frustration and annoyance, in the
other direction.
> e.g.
> fred:
> X=25;echo$$X
>
> With 8 spaces the above is not warned about even though to the human
> eye when you use vim's search function to highlight spaces it becomes
> visually highly suspicious.
>
> 1) it's immediately after a target or
> 2) immediately after a recipe
> 3) it's indented which is an odd thing to do outside of any context such as
> ifeq
#3 is far too broad. You are trying to enforce behavior by
extrapolating from your preferred makefile style.
There are widely-used makefile styles where variable assignments are
often indented. For example, some people use a style where the "=" is
aligned and the variable name is right-justified:
FOO = bar
ANOTHER_VAR = biz
SOME_VAR = baz
Plus, remember that make's syntax is very forgiving of "blank lines"
within recipes, which includes comments. Consider this makefile:
KEEP = false
target:
@echo command
# Now we do some other stuff
ifeq ($(KEEP),true)
keep:
@echo keep
endif
# and this is something else
FOO=bar
How does make interpret the "FOO=bar"? To make, because all the text
between the last "target" recipe line and the assignment is either
removed or are comments, that assigment (if it started with a TAB) would
be considered part of the "target" recipe. If we start to allow random
whitespace at the beginning of a line to mean "part of a recipe", things
will start to break all over the place in unusual ways.
> I'm not suggesting that there's any truly satisfactory way to be sure
> of this but even if an "info" message appeared or an "NB" or if one
> had to switch on some special warning mode that was extra picky -
> whatever it was would be handy and perhaps discourage people from
> using styles that could end up in confusion. 50 years down the line
> for gmake 5 our children might then switch from notification to
> warning and finally enforcement of something.
We have, since 3.82 was released, a way of avoiding this problem with
the .RECIPEPREFIX variable. I think that's the right way forward,
rather than trying to introduce heuristics based on some idea of "common
styles", which will invariably be incorrect in some situations.
There are a lot of possible things make could warn about, that it
doesn't currently. I just think trying to have make attempt to
understand the semantics of makefiles (what the programmer "meant") will
be wrong often enough that it won't be considered useful by most.
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
