Update of bug #64185 (group make):
Status: Fixed => None
Open/Closed: Closed => Open
Fixed Release: SCM => None
_______________________________________________________
Follow-up Comment #12:
The change I made here is causing too many problems with real-world makefiles,
so I'm reverting it and reopening this issue.
I have made a change which generates a warning for any directive which is
indented with a TAB character (in situations where it's NOT considered part of
a recipe). While this still is annoying and leads to confusion in the
situations originally reported, at least you'll get a warning now even though
the makefile is still mis-parsed and the "else" is considered a directive
instead of part of a recipe as intended.
In a release (or two) after people have some time to adjust their makefiles
due to this warning, we can change this warning into an error and then assume
that ANY string which is indented with a TAB cannot be a directive.
I've also adjusted the documentation to make this syntax more obvious with an
up-front admonition instead of leaving it buried at the end of a sub-section.
A few extra notes from below:
> While you keep explaining what the parser is currently doing, what I am
> reporting is that this is not the correct behavior as described by the GNU
> Make documentation.
What Dmitry is trying to give is the answer to these comments of yours:
> However, if you uncomment makefile.blah, line 15, make sees the else
> statement in the 'junk' recipe as part of the conditional. This is odd as
> that line is simply a $(warning ...) logging call.
and:
> The error is caused not by the else in the recipe, but when adding the
> $(warning ...) statement immediately preceding the make else. That is what
> appears to cause the parser to behave incorrectly, and I don't see any reason
> for such a statement to affect parsing behavior at all.
Dmitry is showing why it makes a difference when you uncomment that warning
line: although to you it just looks like a "logging call", in reality that
line forces make to complete the parsing of the recipe for the previous target
(because it's a line that is not indented with a TAB). After that call, make
doesn't consider subsequent lines to be in a "recipe context" and this "recipe
context" makes all the difference to the way the parser currently interprets
TAB-indented conditionals.
I fully agree that it is wrong _according to the documentation_, but that's
how it actually works and we've discovered that in the real world, lots of
makefiles out there currently rely (unknowingly) on this behavior.
> 2. Conditional directives cannot be confused with recipe lines because they
> cannot begin with a tab character. The documentation should be updated to
> refer to the .RECIPEPREFIX character, which did not exist prior to Make
> 3.82.
I don't think this is correct. I think the documentation should continue to
say that directives cannot have a TAB as the first character, regardless of
the value of RECIPEPREFIX.
If RECIPEPREFIX has been changed to something else, then clearly any line
beginning with that character is intended to be part of the recipe so there's
no confusion here. It's only the TAB character, which serves double-duty as
both indentation AND as a recipe introducing character, that has this
problem.
In theory we COULD say that it's OK to use a TAB as the first character on a
directive line IF AND ONLY IF the RECIPEPREFIX has been changed to something
besides TAB. But, I think this is too confusing for not much benefit. I'd
prefer to simply say, it's never allowed to start a directive line with a TAB.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?64185>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
