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