2 messages in com.perforce.jamming[jamming] Building different objects ...| From | Sent On | Attachments |
|---|---|---|
| Kimpton, Andrew | 11 Dec 2001 12:57 | |
| Matt Armstrong | 11 Dec 2001 14:40 |
| Subject: | [jamming] Building different objects from different sources with the same n ame![]() |
|---|---|
| From: | Matt Armstrong (matt...@lickey.com) |
| Date: | 12/11/2001 02:40:12 PM |
| List: | com.perforce.jamming |
"Kimpton, Andrew" <aw...@pulse3d.com> writes:
We use Jam to build our product(s) from a single hierarchical source tree. We place the Binary output files into a separate hierarchy using LOCATE_TARGET.
Many of our 'components' have dependencies on each other so to minimise build times we use SubDir and SubInclude - for example :
Component A (an executable) uses Component B (a shared library) which in turn is built from some static libraries (C & D) and other sources.
Our Jamfiles have
A/Jamfile :
Subdir TOP A ;
If !$(s) { SubInclude TOP B ;
SubInclude TOP C ; SubInclude TOP D ; }
<Blah-blah>
LinkLibraries A$(SUFEXE) : B$(SUFLIB) ;
---
B/Jamfile :
Subdir TOP B ;
If !$(s) { SubInclude TOP C ; SubInclude TOP D ; }
<blah-blah>
LinkLibraries B$(SUFSHR) : C$(SUFLIB) D$(SUFLIB) ;
---
We use the !$(s) so that individual pieces can be built independantly.
A problem has arisen however since components A & B both have a source file xyz.c one in A/xyz.c the other in B/xyz.c
Usually grist takes care of things like this. A/xyz.c will be known as <A>xyz.c and B/xyz.c will be known as <B>xyz.c.
If only B is built things work fine, however if we build A and rely on dependancies to trigger the build of B building B$(SUFDLL) uses A/xyz.c NOT B/xyz.c.
I've tried working with SEARCH_SOURCE, LOCATE_* et al all to know avail. Things are perhaps made even more complicated by the fact that 90% of the time the builds are running on Windows (the other 10% is Unix - and I don't want to break those builds 8-)
Many thanks for any thoughts/comments
For the runs that do not work, I'd just run jam with a high debugging level and redirect its output to a file. jam -d7 spits out more than enough. Then just search for xyz.c within jam's output to see what is happening with it. The two xyz.c files should be differentiated with grist, as I describe above.
-- matt




