[Boost-build] conditional differences between requirements and usage-requirements with <define>

Subject: [Boost-build] conditional differences between requirements and usage-requirements with <define>
From: Ryan Gallagher (ryan.gallagher_at_[hidden])
Date: 2009-09-03 13:25:44

I have a situation where I'd like to change the include path for a 
library based upon whether or not a <define> is set to 0.  Further,
this should be propagated through the usage requirements.  (The 
actual case is "google test" + "google mock" where if 
GTEST_USE_OWN_TR1_TUPLE = 0 then I wanted to make sure that boost's
tr1 tuple is in the include path.)

I'm probably not doing this right but my first attempt was:

### gmock/gtest/Jamfile ###

project gtest : source-location $(GTEST_DIR)/src ;

local BOOST_TR1_PATH = $(BOOST_ROOT)/boost/tr1/tr1&&$(BOOST_ROOT) ;

lib gtest
   : gtest-all.cc                   # sources
   : <include>$(GTEST_DIR)          # requirements
     <include>$(GTEST_DIR)/include
     <define>GTEST_USE_OWN_TR1_TUPLE=0:<include>$(BOOST_TR1_PATH)
   : <link>static                   # default-build
   : <include>$(GTEST_DIR)/include  # usage-requirements
     <define>GTEST_USE_OWN_TR1_TUPLE=0:<include>$(BOOST_TR1_PATH)     
  ;

###

I should probably be using a <conditional> anyways, but the results
where interesting.  The usage-requirements (as given by 
--debug-building) showed that 
"<include>$(BOOST_ROOT)/boost/tr1/tr1&&$(BOOST_ROOT)" 
is inherited by gmock (a target which uses this one).  However, 
the target requirements for gtest instead include: 
<define>GTEST_USE_OWN_TR1_TUPLE=0:<include>...
i.e. -DGTEST_USE_OWN_TR1_TUPLE=0:<include>...

While I'd prefer this syntax, the requirements is probably right to 
do this.  However, the inconsistency between the requirements and 
usage-requirements is what gets me.  How come one they are parsed 
differently?  Is there a reason for this or is it a bug?  Is there
anyway we could keep this syntax (such a requiring quotes in
<define> if it includes a ':')?

I'm doing this with boost build v2 from Boost 1.39.0.
Thanks for any clarification and suggestions,

-Ryan