6 messages in com.perforce.jamming[jamming] layered dependencies and sh...| From | Sent On | Attachments |
|---|---|---|
| Brett Calcott | 31 May 2001 16:38 | |
| David Turner | 01 Jun 2001 01:52 | |
| Dave Lewis | 01 Jun 2001 07:47 | |
| Kimpton, Andrew | 01 Jun 2001 09:27 | |
| David Turner | 01 Jun 2001 10:58 | |
| Kimpton, Andrew | 01 Jun 2001 11:53 |
| Subject: | [jamming] layered dependencies and shared libs |
|---|---|
| From: | David Turner (davi...@freetype.org) |
| Date: | 06/01/2001 10:58:56 AM |
| List: | com.perforce.jamming |
Hi Andrew,
One problem however we have found is that the link rule when used with the Microsoft Library manager (we mostly build for Windows) supplies a 'TOP relative' path. This path seems to change unfortunately depending on the 'depth' relative to TOP when you invoked Jam. This in turn means that the same object (a.obj) can be passed to link as ../../build/a/a.obj and ../../../build/a/a.obj. The microsoft lib tool treats these as different members of the archive since the paths are different although in reality they are the same - which is not good.
The "Library" and "LibraryFromObjects" rules use the "grist" path that is re-computed by each SubDir invocation. Indeed, this is done by the following line of the Jambase:
rule SubDir { ... SOURCE_GRIST = [ FGrist $(<[2-]) ] ; ... }
As you can see, the grist is only composed from the second-to-last parameters to the SubDir rule. This means that the two following commands:
SubDir PROJECT1_TOP src ; SubDir PROJECT2_TOP src ;
will produce the same grist, even if "PROJECT1_TOP" and "PROJECT2_TOP" correspond to completely different directories
Maybe this may help you solve your problem..
By the way, I don't understand well why you'd want to link the same object file to two different libraries or programs that are placed in different directories ? Could you enlighten us with a practical example ??
Regards,
- David