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-18 23:16:25

   Hi.

> On 07/15/2012 10:00 PM, Jurko Gospodnetić wrote:
> The problem is that Boost.Build is creating
> two targets for the same file.  <p...>x.cpp
> is the actual target that is created by the
> action. <p...-object(c-scanner)@...>x.cpp
> refers to the same file, but has a scanner
> attached.  virtual-target.jam currently
> models this with DEPENDS, which doesn't
> quite have the right behavior.  If we use
> SEARCH for <p...-object(c-scanner)@...>x.cpp,
> Boost.Jam knows to bind it to the existing
> target, and we can leave out DEPENDS.

   Ok, I think I finally understand your original answer (heh, takes a 
bit longer for some of us... :-D)... and about 90% of it fits... :-)

   A couple of questions though:

-- 1 --

   Why would replacing the

     DEPENDS <scanner>x.cpp : x.cpp ;

   relationship with

     INCLUDES <scanner>x.cpp : x.cpp ;

   Cause problems?

   I tried it, it makes sense, fixes the problem at hand and no internal 
Boost Build tests fail with that code.

-- 2 --
   I tried removing that DEPENDS relationship declaration all-together 
and replacing it with (code from virtual-target.actualize()):

   SEARCH on $(name) = [ path ] ;

   However - this does not not cause any <scanner>x.cpp --> x.cpp 
dependency to be added and so the action for building x.o gets run 
without x.cpp being generated first.

   Am I missing something here or do we need to manually add a dependency
between whomever is using <scanner>x.cpp and x.cpp? Effectively - this 
is the exact dependency added internally by having <scanner>x.cpp 
INCLUDE x.cpp.

   Best regards,
     Jurko Gospodnetić