15 messages in com.perforce.jamming[jamming] INCLUDES bug?| From | Sent On | Attachments |
|---|---|---|
| Steve Goodson | 22 Nov 2002 21:34 | |
| davi...@rcn.com | 23 Nov 2002 12:03 | |
| Matt Armstrong | 24 Nov 2002 15:35 | |
| davi...@rcn.com | 24 Nov 2002 15:41 | |
| Christopher Seiwald | 02 Dec 2002 09:11 | |
| Vladimir Prus | 03 Dec 2002 03:34 | |
| Arnt Gulbrandsen | 03 Dec 2002 04:06 | |
| Vladimir Prus | 03 Dec 2002 04:29 | |
| Vladimir Prus | 03 Dec 2002 04:49 | |
| Arnt Gulbrandsen | 03 Dec 2002 06:26 | |
| Vladimir Prus | 03 Dec 2002 09:56 | |
| Christopher Seiwald | 03 Dec 2002 10:46 | |
| Vladimir Prus | 03 Dec 2002 11:23 | |
| davi...@rcn.com | 03 Dec 2002 11:53 | |
| Christopher Seiwald | 10 Dec 2002 00:59 |
| Subject: | [jamming] INCLUDES bug? |
|---|---|
| From: | Vladimir Prus (gho...@cs.msu.su) |
| Date: | 12/03/2002 11:23:48 AM |
| List: | com.perforce.jamming |
Christopher Seiwald wrote:
| Suppose that there are two generated files a.cpp and b.h, and a.cpp includes | b.h. Naturally, I'd like b.h to be generated before a.cpp is compiled.
We do this all the time, simply by having the rule that generates a.cpp explicitly state the INCLUDES of b.h. If a.cpp is generated from some other source file, scan _that_ file for includes and propagate them down (using the special variables HDRRULE and HDRSCAN).
This seems non-trivial to implement in a generic way, but I'll think about it.
What I acknowledge is weak is that the header scanning only really works with the include syntax of a few languages. I also acknowledge that writing rules that set and use HDRRULE and HDRSCAN can be intricate. We hope to have publishable examples at some point.
I'm rather interested in your opinion on the other issue I've raised: the fact that the generated header target that is created, is different from the target created during dependency scanning. (In particualar, the latter contains include paths in grist for Boost.Build). This results in missed dependency. Do you think it's a problem?
- Volodya