Bug 87623 - if foo.h is older than foo.y, then yacc does not get run
if foo.h is older than foo.y, then yacc does not get run
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: automake (Show other bugs)
7.3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Reed
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-03-31 00:18 EST by Bradley C. Kuszmaul
Modified: 2007-04-18 12:52 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-02 18:16:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bradley C. Kuszmaul 2003-03-31 00:18:48 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
Suppose that, for some reason, I get into a state where my foo.h file is older
than my foo.y file, but my foo.c file is up-to-date.

This happened to me when I had a piece of software stored in a version control
system, and the original authors had placed foo.c, foo.h, and foo.y all into the
version control system.

So when I did make, the following rule fired

foo.h: foo.c
	@if test ! -f $@; then \
	  rm -f foo.c; \
	  $(MAKE) foo.c; \
	else :; fi

Since foo.h was older than foo.c, the rule fired.
But since foo.h existed, nothing happened.

I am not sure the best way to fix this.  One approach might be to fix it for
bison.  Thus if yacc=bison then generate

%.c %.h: %.y
     bison $<

and get rid of all the nonsense about ylwrap.



Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Take a yacc file, foo.y
2. make foo.c
3. touch foo.y
4. touch foo.c
5. make
    

Actual Results:  On step 5, nothing is remade, even though foo.h is older than foo.y


Expected Results:  foo.h should have been rebuilt.

Additional info:
Comment 1 Jens Petersen 2003-11-09 21:33:45 EST
The version of Automake in RHL 7.3 is rather old.
Could you please try with a newer version?

If you can reproduce with recent/current automake,
then could you please attach some example tarball to help
test this problem?
Comment 2 Jens Petersen 2004-01-12 21:01:08 EST
Anyway I suggest taking this issue upstream to one of the automake
lists if it is still present in Automake 1.8.
Comment 3 Jens Petersen 2004-05-12 20:55:20 EDT
Is it possible you could provide a small testcase for this, please?
That would make it easier to look into?
Comment 4 Daniel Reed 2004-08-02 18:16:32 EDT
If this is still an issue with the latest automake, please resubmit
your bug report to <bug-automake@gnu.org>. Thanks.

Note You need to log in before you can comment on or make changes to this bug.