Bug 87623

Summary: if foo.h is older than foo.y, then yacc does not get run
Product: [Retired] Red Hat Linux Reporter: Bradley C. Kuszmaul <bradley-k-redhatbugzilla.856807>
Component: automakeAssignee: Daniel Reed <djr>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-08-02 22:16:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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:
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-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 <bug-automake>. Thanks.