Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 87623 - if foo.h is older than foo.y, then yacc does not get run
Summary: if foo.h is older than foo.y, then yacc does not get run
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: automake
Version: 7.3
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Daniel Reed
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-03-31 05:18 UTC by Bradley C. Kuszmaul
Modified: 2007-04-18 16:52 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-08-02 22:16:32 UTC

Attachments (Terms of Use)

Description Bradley C. Kuszmaul 2003-03-31 05:18:48 UTC
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:

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-10 02:33:45 UTC
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-13 02:01:08 UTC
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-13 00:55:20 UTC
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 22:16:32 UTC
If this is still an issue with the latest automake, please resubmit
your bug report to <>. Thanks.

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