4 messages in com.perforce.jamming[jamming] rule File?| From | Sent On | Attachments |
|---|---|---|
| Craig Allsop | 12 Sep 2002 23:13 | |
| Matt Armstrong | 13 Sep 2002 06:18 | |
| Craig Allsop | 15 Sep 2002 16:15 | |
| Craig Allsop | 15 Sep 2002 17:28 |
| Subject: | [jamming] rule File?![]() |
|---|---|
| From: | Craig Allsop (call...@auran.com) |
| Date: | 09/15/2002 05:28:34 PM |
| List: | com.perforce.jamming |
I've just tried to create a small test case:
--- a.cpp #include <a.h> void main(){} --- a.h #include <b.h> --- b.h
--- jamfile SubDirHdrs . ; Main a : a.cpp ; File c.h : a.h ;
I was trying to recreate the problem described initially (which it doesn't), however another problem that I'm having trouble with is shown.
The File rule here will cause jam to evaluate the a.h node (as it is dependant on 'files') before the a.cpp node (which adds HDRRULE on it). No headers are scanned on a.h as a result. Take out the File rule from my jamfile and dependancies on a.h are processed as expected.
The problem is, variables are set during the bind pass, sometimes after the fate is already determined. Perhaps the bind pass should comprise of two passes, one for determining header dependencies/variables and another to determine fate? What implications does this have?
Provided that I can overcome this issue, I'd like to compile/link files with c.h as I have one project that generates libraries and headers to a common location in my source tree and several other projects would be compiled/linked against the common ones.
Craig.
----- Original Message ----- From: "Diane Holt" <hol...@yahoo.com> To: "Craig Allsop" <call...@auran.com> Sent: Saturday, September 14, 2002 3:34 AM Subject: Re: [jamming] rule File?
Hi Craig,
Could you explain this a bit more? I'm also doing File's on header files on a Win*, and I want to be sure I understand your issue, so it doesn't bite me as well.
Are you compiling against the copies of the headers, or against the originals? (I am -- and I had a heck of a time getting the re-compiles to work correctly, so if you are and have a simpler approach than the hoops I had to jump through, I'd love to hear about it.)
Also, I'm not sure I understand what actually happens here:
If a dependency is newer than the header being copied, jam will assume the newest time for this header and will always perform the copy because the copy (for NT) uses the same time as the source file (as opposed to the one jam knows).
By "dependency", do you mean the source-code file that #include's the header, or do you mean the "target" header-file (ie., the copy of it)? If the latter, I've not seen that happen (ie., once the copies are done, they only get re-copied when the one in the source tree is newer than the one in the build tree).
Thanks, Diane
===== (hol...@yahoo.com)
__________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com
Auran disclaims responsibility for the contents of this e-mail unless it was expressly authorised by Auran. This e-mail is a confidential communication. To the extent permitted by law, Auran does not accept any liability for any loss or damage suffered or incurred by you as a result of receiving, opening or relying on this e-mail.




