From: Jurko GospodnetiÄ (jurko.gospodnetic_at_[hidden])
Date: 2008-08-12 06:39:58
> 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^
> : NOTFILE ^
> : 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
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...
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk