2 messages in com.perforce.jamming[jamming] Building different objects ...
FromSent OnAttachments
Kimpton, Andrew11 Dec 2001 12:57 
Matt Armstrong11 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.