[Boost-build] Dependency on Boost libs causes problems (Was: Dependency problem with tests run with executable created by another target)

Subject: [Boost-build] Dependency on Boost libs causes problems (Was: Dependency problem with tests run with executable created by another target)
From: Sven Van Echelpoel (sven.van.echelpoel_at_[hidden])
Date: 2009-02-10 03:58:10

Hi,

we managed to narrow down the possible causes until we came to a
dependency on the Boost libraries. In every sub-project we include a
file (attached, boost-libraries.jam) that gives us some aliases to
libraries from the Boost distribution that we use. It is the inclusion
of this file that is causing the problem. More specifically it is this line:

   use-project /boost-libs : $(BOOST_ROOT) ;

Commenting this out make the problem go away. We even managed to reproduce this in the toy project (also attached). Knowing this, the question has changed:

  * Can we include files like this in every sub-project (we do this a
lot with other components too), or does it need to be done differently?

Thanks for any input,

Sven

> 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
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build


#############################################################################
# Jamroot
#
#	This file contains the declarations of the paths and constants
#	required for using the Boost libraries
#############################################################################

import os ;

# Import an environment variable (BOOST_ROOT)
# into a local variable
local BOOST_ROOT = [ os.environ BOOST_ROOT ] ;

# Make an alias for the Boost project. This
# will allow us to reference the Boost libraries
# from within our projects using 
# /boost-libs//<your Boost library here>
use-project /boost-libs : $(BOOST_ROOT) ;

# This is an alias that you can use in the
# dependency list of your projects. It will
# pull in the Boost libraries, set the proper
# include directory and defines.
alias boost-header-only
      : 
      : 
      : 
      : <define>BOOST_ALL_NO_LIB <include>$(BOOST_ROOT)
      ; 

# You can use this alias to use the Boost threading
# library
alias boost-thread
      : boost-header-only /boost-libs//thread
      : <link>static
      ;

# You can use this alias to use the Boost date/time
# library
alias boost-date_time
      : boost-header-only /boost-libs//date_time
      : <link>static
      ;
# You can use this alias to use the Boost filesystem
# library
alias boost-filesystem
      : boost-header-only /boost-libs//filesystem
      : <link>static
      ;

# You can use these aliases to use the Boost test
# library
alias boost-test_exec_monitor
      : boost-header-only /boost-libs//test_exec_monitor
      : <link>static
      ;
alias boost-prg_exec_monitor
      : boost-header-only /boost-libs//prg_exec_monitor
      : <link>static
      ;
alias boost-unit_test_framework
      : boost-header-only /boost-libs//unit_test_framework
      : <link>static
      ;

##########################################
# END OF FILE
###