I'm trying to write a jamfile in an external project that uses boost. The jamfile should invoke the wave tool to preprocess some code as a build action. I have this: actions do_wave { $(>[2]) -o- --config-file wave.cfg $(>[1]) } W = /boost/libs/wave/tool/build//wave ; make preprocess : preprocess.cpp $(W) : do_wave ; I get:
error: Unable to find file or target named error: '/boost/libs/wave/tool/build//wave' error: referred to from project at error: '.' error: could not resolve project reference '/boost/libs/wave/tool/build'
If I use this instead: W = /boost//wave ...it builds the wave dlls, not the command-line tool. So how do I tell it to build the tool? -- Eric Niebler Boost.org http://www.boost.org
AMDG On 01/13/2014 04:18 PM, Eric Niebler wrote:
I'm trying to write a jamfile in an external project that uses boost. The jamfile should invoke the wave tool to preprocess some code as a build action. I have this:
actions do_wave { $(>[2]) -o- --config-file wave.cfg $(>[1]) }
W = /boost/libs/wave/tool/build//wave ;
Either you need to give the path to the wave project: W = $(BOOST_ROOT)/path/to/wave//wave ; or you need to declare this project-id somewhere: use-project /boost/libs/wave/tool/build : $(BOOST_ROOT)/path/to/wave ; Alternately, the wave Jamfile can be modified to give itself an id: project /boost/libs/wave/tool/build ; In Christ, Steven Watanabe
On 1/13/2014 8:01 PM, Steven Watanabe wrote:
AMDG
On 01/13/2014 04:18 PM, Eric Niebler wrote:
I'm trying to write a jamfile in an external project that uses boost. The jamfile should invoke the wave tool to preprocess some code as a build action. I have this:
actions do_wave { $(>[2]) -o- --config-file wave.cfg $(>[1]) }
W = /boost/libs/wave/tool/build//wave ;
Either you need to give the path to the wave project:
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?
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.
Alternately, the wave Jamfile can be modified to give itself an id:
project /boost/libs/wave/tool/build ;
Not a bad suggestion. Hartmut? -- Eric Niebler Boost.org http://www.boost.org
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
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
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?
I believe that before the wave tool was build using static libraries. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
participants (3)
-
Eric Niebler -
Hartmut Kaiser -
Steven Watanabe