bug-make
[Top][All Lists]
Advanced

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

[bug #27609] Stupid inference rule for yacc files can clobber C sources!


From: Kaz Kylheku
Subject: [bug #27609] Stupid inference rule for yacc files can clobber C sources!
Date: Mon, 05 Oct 2009 19:36:10 +0000
User-agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)

URL:
  <http://savannah.gnu.org/bugs/?27609>

                 Summary: Stupid inference rule for yacc files can clobber C
sources!
                 Project: make
            Submitted by: kkylheku
            Submitted on: Mon 05 Oct 2009 12:36:09 PM PDT
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
       Component Version: 3.80
        Operating System: Any
           Fixed Release: None
           Triage Status: None

    _______________________________________________________

Details:

I have a project in which there is a lex grammar and yacc grammar. Let's call
them foo.l and foo.y.   It's somewhat of a tradition to use the same name for
both. There is no interference because one is translated to a lex.yy.c, and
the other to y.tab.c.

So, silly me, I decided to add a third file, a main driver program, which I
called foo.c, thinking that all three files foo.l, foo.y and foo.c would be
independent.

In my Makefile, I added the dependency, by naming foo.o as a prerequisite of
the main program. But I did not add a rule for how foo.o is obtained; all my
other .o files have implicitly deduced .c prerequisites.

Lo and behold, when I ran make, this happened:

  mv -f y.tab.c foo.c

There goes my foo.c file! Apparently, foo.c is connected to foo.y by
prerequisite inference.

What kind of moron writes implicit rules, to be shipped in the default rule
set of a make program, which guess up .c file names and proceed to clobber
them?

And since when has foo foo.c ever been related to foo.y as a derived object?

If I want my y.tab.c to be called something else, I will write the rule for
it.

Luckily the contents of foo.c came from another file which is under version
control. I lost only two very minor edits.





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27609>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/





reply via email to

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