Boost logo

Boost-Build :

From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2008-08-12 06:39:58

   Hi all.

> But I also see this:
> -> 3 Name: <pC:\libs\Boost_1360_x86\boost\bin.v2\libs\filesystem\build\msvc-9.0\release\address-model-32\architecture-x86\threading-multi>boost_filesystem-vc90-mt-1_36.lib (interna
> : Updating it^
> : Depends on <pC:\libs\Boost_1360_x86\boost\bin.v2\libs\filesystem\build\msvc-9.0\release\address-model-32\architecture-x86\threading-multi>boost_filesystem-vc90-mt-1_36.d
> which seems fairly weird -- I don't see why import library would depend on DLL, nor why
> would it be marked NOTFILE.
> Can you check if similar anomaly happens on small case, such as the libraries example,
> under msvc?

   Just as information to everyone we already tracked down that wield
'dll on import library' dependency. It is added by Boost Jam in
evaluate_rule() in compile.c in case when a single action generates
multiple targets.

   Here all of the non-initial generated targets are made to depend on
the initial one. This seems to have been introduced by Rene in revision
39341 as a fix for some multi-processor build bug (issue #431) inherited
from the original Jam.

   We tried removing this and it does not seem to affect the original

   Here I am not really sure about some internal details of how this
works (why 'includes' relationship is being used here instead of
'depends' internally), but I'll take that up with Rene...

   Best regards,
     Jurko Gospodentić

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at