8 messages in com.perforce.jamming[jamming] Re: blah.y depends on itself| From | Sent On | Attachments |
|---|---|---|
| Arnt Gulbrandsen | 04 Dec 2003 10:12 | |
| Anthony Heading | 07 Dec 2003 19:15 | |
| Paul Forgey | 07 Dec 2003 21:04 | |
| Arnt Gulbrandsen | 08 Dec 2003 04:08 | |
| Christopher Seiwald | 08 Dec 2003 14:26 | |
| Arnt Gulbrandsen | 09 Dec 2003 01:27 | |
| Christopher Seiwald | 09 Dec 2003 08:39 | |
| Arnt Gulbrandsen | 09 Dec 2003 09:26 |
| Subject: | [jamming] Re: blah.y depends on itself |
|---|---|
| From: | Christopher Seiwald (seiw...@perforce.com) |
| Date: | 12/09/2003 08:39:01 AM |
| List: | com.perforce.jamming |
Arnt said:
IMO, no. The Yacc rule is wrong, and I'm glad you fixed it, but the condition for the warning is wrong too.
The warning is emitted for X if there is a circular chain of Includes and Depends where the dependency pointing to X is a Depends. If nothing else, that condition is too obscure to be correct. The warning should be emitted if there is a chain of Depends.
Hmmm. I don't think the condition is too obscure. Certainly, if you need a .c file to generate a .h file, and the .c file includes the .h file, you've got a circular dependency. This was the problem with the Yacc rule: it said to make the .c/.h files you needed the .y file, but the .y file appeared to include the .h file. How is anything (other then that Yacc rule) to know that a .y file #including a .h file means something other than that the .h file is necessary to proceed with the .y file?
/*! The Mumble library contains many easy-to-use functions to help you mumble more effectively. To use them, simply add #include <mumble.h> and call the functions. Blah blah blah. */
If you're trying to confuse the cheap-and-cheerful HdrRule, putting a #include in comments in the way to go.
Depends foo : foo.o ; # from Main Depends foo.o : foo.h ; # From Includes foo.c : foo.h ; Depends foo.o : foo.c ; # From Object Depends foo.h : foo.h : # from cproto rule (I think you mean "foo.h : foo.c" here.) Includes foo.c : foo.h ; # observed in foo.c
If you're generating two different things from the same .c file -- both the .o and a .h, then the stock HdrRule isn't enough: it only assumes that everything generated from the .c file will require the contents of the .h file.
If you look closely at this, there's nothing that can break. If foo.c is modified or foo.h is removed, cproto must be run and then cc. Else, nothing need be done.
If you modify the .h, the dependencies you have listed will require the .h to be regenerated. I'm not sure I'd call that broken, but it is hardly ideal.
In this last case, you could have a special HdrRule for cproto files, that knows that the .h is generated from everything in the .c file except for the included .h. Or perhaps jam could use a "Ignore this tangled web" target modifier for such situations.
Christopher