bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Bug in pattern rule parsing: how to handle?


From: Paul Smith
Subject: Bug in pattern rule parsing: how to handle?
Date: Sun, 26 Oct 2008 17:48:11 -0400

Hi all;

While working on some changes to 2nd expansion etc. to try to reduce
total heap usage in GNU make, I've discovered that there is a bug in the
current makefile parsing.  My new version doesn't have this bug (or,
more precisely, it contains the opposite bug) and I've noticed at least
two different build environments that stop working due to this: one is
glibc and one is the Linux kernel (!)

So, the question is, what should we do about this?

Here's the issue: if you write a rule like this:

        foo %.c: ; @: oops

it actually works!  This, I believe, should be illegal.  Indeed, if you
write the rule like this instead:

        %.c foo: ; @: oops

then it fails with an error "mixed implicit and normal rules".  It's
actually an accident of parsing that we don't catch the first case: we
walk through the list and we don't recognize that we're in a pattern
rule until we hit the first target that contains a "%".  So, the first
example (that works) is treated by GNU make as:

        foo: ; @: oops
        %.c: ; @: oops

I really don't think this is correct... certainly treating things
differently based on the order they appear is not correct!  (I found
this problem because in my environment I happen to be walking this list
backwards at the time, so I fail on the first example but the second one
now succeeds).

I can see these choices going forward:

     1. Ignore the problem and reproduce the old behavior in the next
        version of make, but don't document it so we can change it in
        the future (cheap!)
     2. Reproduce the old behavior, and document it so that it becomes
        the official behavior of GNU make.
     3. Reproduce the old behavior but generate a warning so that in
        future versions of make we can change it so that any normal
        target in an implicit rule generates an error.
     4. Fix make now so that it generates an error for this situation.

I prefer #4, or if not then #3.  If anyone has any opinions or comments
let me know.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.mad-scientist.us
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist




reply via email to

[Prev in Thread] Current Thread [Next in Thread]