Re: [Boost-build] Failing dependency_test.py test.

Subject: Re: [Boost-build] Failing dependency_test.py test.
From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2012-07-16 08:47:40

   Hi.

> The problem is a result of these dependencies:
>
> INCLUDES x.cpp : x.bar ;
> DEPENDS <object(c-scanner)>x.cpp : x.cpp ;
>
> The result is that <object(c-scanner)>x.cpp
> (which binds to x.cpp) depends on x.bar.

   Ok, what if we could avoid the INCLUDES x.cpp : x.bar all together?

   I found that the include in question is added in virtual-target.jam 
in the action.actualize() rule where all targets are said to include 
each other. There is also the following comment above this code:

   # This works around a bug with -j and actions that produce multiple
   # target, where:
   # - dependency on the first output is found, and the action is
   #   started
   # - dependency on the second output is found, and bjam noticed that
   #   command is already running
   # - instead of waiting for the command, dependents of the second
   #   targets are immediately updated.

   If we updated Boost Jam to work correctly in this case there would be 
no more need for this INCLUDE, right? (and that part of Jam code is 
something I am more familiar with than this internal-node/scanner 
handling... :-D)

   On the other hand, I can see there being an actual need in some build 
to mark targets generated by the same action as including each other. In 
that case - we would be back at the original problem so I guess a clean 
fix for that situation is still needed, but I have still not managed to 
'parse' your answers on that subject... but - getting closer one step at 
a time. :-)

   Best regards,
     Jurko Gospodnetić