John Maddock wrote:
That will be great! Any chance this will be done in near future? It's a quick change and it's needed so that I can formally check that test results with Boost.Build V1 and V2 are the same. If you tell me the prefix you like I can adjust the Jamfile myself.
I've updated the v1 Jamfile, but not v2 (sorry for the slight delay, but you caught me just as I was calling it a day).
Thanks!
Re: the v2 Jamfile: I don't think the global project requirements you've added are such a good idea: it means that the std-library-forwarding headers are always in the search path even when they're not supposed to be tested, if there's a SNAFU with their setup then *everything* will fail, which makes my job rather harder.
You're right, I've already notices that those tests fail with V2, and locally fixed the problem.
I also had to explicitly add BOOST_ROOT to the include paths because there were some v1 toolsets that put compiler-specific (or STLport) paths *before* boost's. I can't tell you how subtle the problems are that this causes (the header forwarding mechanism is *very* sensitive to include path order unfortunately, especially when STLport is trying to do the same thing), or how hard they are to track down. Hopefully bbv2 is umm, more sane in this area, and doesn't needlessly inject compiler include paths into the mix?
This should be checked, because I actually don't know if what order compilers such as MSVC process includes. V2 invokes vcvars32.bat before running the compiler.
And finally: in the v1 Jamfile I had to use full paths in the GLOB statements to get them to work when the Jamfile was being referenced from status/ rather than it's own directory. Is bbv2 any beter here?
Yes, I have no problem when running from /status. In V2, the 'glob' rule operates relatively to Jamfile where it's used. Thanks for your help. I've updated Jamfile.v2 and hopefully I'll soon have exactly the same test results in V1 and V2, at least on Linux. - Volodya