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.  */

+          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:


Message sent via Savannah

Reply via email to