Re: [boost] [build] referring to a tool from an external project

Subject: Re: [boost] [build] referring to a tool from an external project
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2014-01-15 11:07:21

AMDG

On 01/14/2014 10:03 PM, Eric Niebler wrote:
> On 1/13/2014 8:01 PM, Steven Watanabe wrote:
>> 
>> W = $(BOOST_ROOT)/path/to/wave//wave ;
> 
> Right, thanks. And BOOST_ROOT needs to be defined somewhere. Which leads
> to my next question. One level up in my directory tree is where I have a
> boost-build.jam that does all the hard work of processing command-line
> arguments (e.g. --boost=...) and looking at environment variables to
> determine where boost is. It sets a BOOST variable like so:
> 
> BOOST ?= $(boost-src) ;
> 
> I was under the naive assumption that since this variable wasn't
> "local", it would be visible to all the Jamfiles in all the
> sub-directories. But that seems not to be the case, since in my Jamfile,
> $(BOOST) is empty. Where have I gone wrong?
> 

boost-build.jam is run in the global module.
Variables are only visible in the module
in which they are defined.  (Functions in
the global module are visible everywhere,
variables are not).  To access this variable,
you need to use [ modules.peek : BOOST ].

>> or you need to declare this project-id somewhere:
>>
>> use-project /boost/libs/wave/tool/build : $(BOOST_ROOT)/path/to/wave ;
> 
> Would it be a good idea to add it to the super-repository's Jamroot? It
> does something similar for the inspect tool:
> 
> use-project /boost/tools/inspect : tools/inspect/build ;
> 
> Many of the libraries have Jamfiles that use the wave tool to preprocess
> their sources. Those are all currently broken by modularization.
> 

This is probably the best solution.

>> Alternately, the wave Jamfile can be modified to give itself an id:
>>
>> project /boost/libs/wave/tool/build ;
> 
> Not a bad suggestion. Hartmut?
> 

Unfortunately, this only works if the Jamfile is
already being loaded.

In Christ,
Steven Watanabe