Steven, thanks for your help. I have a new question below... On 1/15/2014 8:07 AM, Steven Watanabe wrote:
On 01/14/2014 10:03 PM, Eric Niebler wrote:
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 ].
Yup, thanks.
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.
I went ahead and added this to the super-repo's Jamroot: use-project /boost/libs/wave/tool : libs/wave/tool/build ; That helps. Now I'm working on getting the Jamfiles in Boost working that try to call the wave tool. In libs/proto/preprocess, I have a Jamfile that uses the wave tool to preprocess Proto's headers. It looks simply like this now: actions wave { $(>[2]) -o- -DBOOST_PROTO_MAX_ARITY=10 --config-file wave.cfg $(>[1]) } W = /boost/libs/wave/tool//wave ; make preprocess_proto : preprocess_proto.cpp $(W) : wave ; That causes the wave tool and all its dependencies to get built (good), but it fails to run. I get the following pop-up: "The program can't start because boost_wave-vc110-mt-gd-1_55.dll is missing..." This worked before. Clearly modularization necessitates I do something extra to get the executable search path correct, but I don't know what that something is. Any help? -- Eric Niebler Boost.org http://www.boost.org