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 04:29:41 AM |
| List: | com.perforce.jamming |
Arnt Gulbrandsen wrote:
Vladimir Prus writes:
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.
But this is not 100% satisfactory. If you add "-j" option to the command line, correct building order is not guaranteed, and this is indeed a problem for me.
If I understand that correctly, the problem is not really the build order. The build order merely makes the problem show up. Even if jam builds a.cpp "after" b.h, there isn't any guarantee that building of b.h has been finished by the time use of a.cpp starts
You really need to express, explictly, that a.cpp depends on b.h. That b.h must exist by the time a.cpp is used. Build order doesn't do that; only dependencies do.
That's what I meant. I'd like to have explicit dependencies on b.h.
An optimal solution would be to run 'headers' on generated targets *after* they are generated.
In that case, jam can't run anything else until it has built any generated headers, because it does not know when actions are runnable. Right?
I don't follow you. If "a.cpp" is to be updated, then dependents will wait for it. I suggest that after it's physically updated (i.e. the action is run), you run headers(), which adds some includes. So dependents will have to wait a little longer. But other targets are not affected.
What, then, if a.cpp does not exist yet, and is (will be) the only file that includes b.h? a.cpp cannot be generated before b.h is generated because jam doesn't know the appropriate action order, but there's no reason to generate b.h at all (yet).
a.cpp *can* be generated before b.h! It cannot be compiled before b.h is generated.
I don't think jam's header scanning can handle cases like this. You simply must express such dependencies in the Jamfile.
I'm not fond about this idea. Boost.Build has rather high level interface and explicit dependencies like that would look wrong.
What jam could practically do is detect the error: If a file has been header-scanned and is subsequently generated, jam can detect that and give an error.
Does it mean that you cannot generate cpp files?
This will not change fate of any target, only adjust build order.
I believe the example I just gave shows a change of fate for b.h.
I still don't understand. Can you elaborate?
- Volodya