Follow-up Comment #9, bug #64185 (project make): I agree that this is simply a bug. There are definitely places where it's impossible to "do the right thing" with relation to GNU Make's conditionals, because there is no easy way to tell them apart from non-conditional statements (this is the difference between GNU Make's conditionals and the C preprocessor's conditionals, which use an invalid syntax).
However, this example plainly contravenes the explicit text of the documentation AND I don't see any reason for it to do so, so I think it's a bug. It seems simple to fix as well: diff --git a/src/read.c b/src/read.c index 4e8432a0..6748486e 100644 --- a/src/read.c +++ b/src/read.c @@ -666,16 +666,16 @@ eval (struct ebuffer *ebuf, int set_default) /* Ignore the commands in a rule with no targets. */ continue; + if (ignoring) + /* Yep, this is a shell command, and we don't care. */ + continue; + /* If there is no preceding rule line, don't treat this line as a command, even though it begins with a recipe prefix. SunOS 4 make appears to behave this way. */ if (filenames != 0) { - if (ignoring) - /* Yep, this is a shell command, and we don't care. */ - continue; - if (commands_idx == 0) cmds_started = ebuf->floc.lineno; Plus some tests need to be written of course. If someone has a thought of something this might break (other than people indenting their conditionals with the recipe prefix) please let me know because I can't think of one. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?64185> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/