Tobias Schwinger wrote:
Vladimir Prus wrote:
Tobias Schwinger wrote:
Beman Dawes wrote:
Thanks for tracking this down, Volodya!
Tobias, what's going on here? Can you fix it? I think it might be fixed on the trunk, already. That is, the targets are all /explicit/ now so the problems should be gone. I consider myself a "basic user" of Boost.Build however, so maybe Volodya should take a second look and possibly give me some hints for further improvements :-). 'explicit' will cause those targets not to build for regular install, so it will fix the problem.
There's one issue though -- I think that 'function_types' will still appear in output of
bjam --show-libraries
in boost root. That is supposed to give the list of buildable libraries, and since function_types does not really buildable/installable.
We probably can either move that Jamfile somewhere else (say, build/util/Jamfile) and add a comment to the Jamfile that is requires Wave built and installed, and that Jamfile is for maintaining the library, or we can teach top-level Jamroot to ignore this Jamfile.
I'd suspect moving it is better, it reduces a potential for confusion.
Understood, thanks.
What are the top-level scripts globbing for?
It's globbing for the build/Jamfile...
When I rename the 'build' directory to 'preprocess' all problems are gone and I could also remove the 'explicit's, right?
As you noticed there :-) So yes, you no longer need the explicits.
In that case, would it be possible to trigger the Wave tool to be built automatically?
Yes, you'd have to add a <dependency> to the tool target at minimum. The hard part is getting the path to it correctly so you can invoke it. As assuming it's in the path is not possible. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail