[Boost-build] Dependency problem with tests run with executable created by another target

Subject: [Boost-build] Dependency problem with tests run with executable created by another target
From: Sven Van Echelpoel (sven.van.echelpoel_at_[hidden])
Date: 2009-02-09 05:23:18

Hi,

Last week I asked a question on this ML about how to set up tests with
an executable created by another target
(http://www.nabble.com/Running-tests-with-executable-built-by-another-target-to21727535.html). One poster (Alexander Sack) pointed me to an earlier discussion (http://www.nabble.com/Building-a-generator-binary-then-using-it--to19961814.html#a19963245) which was very helpful.

We tried to integrate this in our project and initially we were
successful. However, when we tried to expand it, we ran into trouble.
Let me first try to describe what we are trying to achieve. We are
building an executable that we want to test (some sort of compiler).
This compiler produces a file that we need to send to yet another
executable to produce some output that we can then compare with a
baseline. The second executable also needs to be built. In essence, what
we are trying is this:

make exe1.out : exe1.in : @exe1 ;
make exe2.out : exe1.out some-other-input : @exe2 ;

Doing this in the toy project that was created by Vladimir Prus to
illustrate the solution works just fine. It's when we try to incorporate
the solution into out project hierarchy that we run into trouble. As
soon as we substitute one of the toy executables from the sample with
one of our own executables BB complains about a duplicate name of an
actual target. Here's the trimmed print out:

error: Duplicate name of actual target:
<pbin/gcc-3.4.6/debug/threading-multi>a.inc
error: previous virtual target { Jamfile<[...]/SomeTest>%
Jamfile<[...]/SomeTest>.SomeExecutable-a.inc. { a.td. } }
error: created from ./a.inc
error: another virtual target { Jamfile<[...]/SomeTest>%
Jamfile<[...]/SomeTest>.SomeExecutable-a.inc. { a.td. } }
error: created from ./a.inc
error: added properties: <python-debugging>off <python>2.5
<threadapi>pthread
error: removed properties: none
[...]/boost_1_36_0/tools/build/v2/build/virtual-target.jam:468: in
actualize-no-scanner from module object(file-target)@5357
[...]/boost_1_36_0/tools/build/v2/build/virtual-target.jam:123: in
object(file-target)@5357.actualize from module object(file-target)@5357
[...]/boost_1_36_0/tools/build/v2/build/virtual-target.jam:766: in
actualize-source-type from module object(action)@5362
[...]/boost_1_36_0/tools/build/v2/build/virtual-target.jam:787: in
actualize-sources from module object(action)@5362
[...]/boost_1_36_0/tools/build/v2/build/virtual-target.jam:728: in
object(action)@5362.actualize from module object(action)@5362
[...]/boost_1_36_0/tools/build/v2/build/virtual-target.jam:289: in
actualize-action from module object(file-target)@5363
[...]/boost_1_36_0/tools/build/v2/build/virtual-target.jam:477: in
actualize-no-scanner from module object(file-target)@5363
[...]/boost_1_36_0/tools/build/v2/build/virtual-target.jam:123: in
object(file-target)@5363.actualize from module object(file-target)@5363
[...]/boost_1_36_0/tools/build/v2/build-system.jam:681: in load from
module build-system
[...]/boost_1_36_0/tools/build/v2/kernel/modules.jam:281: in import from
module modules
[...]/boost_1_36_0/tools/build/v2/kernel/bootstrap.jam:128: in
boost-build from module
[...]/boost_1_36_0//boost-build.jam:16: in module scope from module

Ironically it works if we add two toy executables to our hierarchy
(tblgen and tblgen2). Once we substitute one it falls apart. It also
works if only have one executable (of our own), so this works with out
exe:

make exe1.out : exe1.in : @exe1 ;

As we have been using BB for a while now we have used it to build some
additional infrastructure (e.g. added features and automatically
generated targets so that sub projects could easily refer to others) it
may be that the behavior we see is because of something that we added.
It is hard for us to diagnose the problem, so any help is appreciated. I
cannot actually send you all of our project files, so to get things
started I have a couple of questions:

1. What may be the cause(s) of the above error?
2. How can we start tracking down the cause in our project files? E.g.
is there some more information in the bjam debugging output, or are
there some rules that are more likely to result into this?

I have attached the modified sample project to show what we tried. This
sample is the one that still works.

Thanks in advance,

Sven