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^
> : 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
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
problem.

   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 acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk