Hello! The current CVS version of the TR1 library has two tests named "test_complex", as the following output demonstrates: $ bjam tr1_has_tr1_array_fail -n --dump-tests | grep test_complex boost-test(COMPILE) "tr1/test_complex" : "libs/tr1/test/test_complex.cpp" boost-test(COMPILE) "tr1/std_test_complex" : "libs/tr1/test/test_complex.cpp" boost-test(COMPILE) "tr1/test_complex" : "libs/tr1/test/test_complex.cpp" There are three tests reportedly using "test_complex.cpp", and two tests named "tr1/test_complex". However, regression results at: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/tr1.htm... mention only one test named "test_complex". Further, the first "test_complex" comes from this loop in Jamfile: for local file in [ GLOB $(BOOST_ROOT)/libs/tr1/test : test*.cpp ] { all_rules += [ compile $(file) : <include>$(BOOST_ROOT) ] ; and the second "test_complex" comes from this loop: for local file5 in [ GLOB $(BOOST_ROOT)/libs/tr1/test/std_headers : *.cpp ] { all_rules += [ compile $(file5) Note that the output of --dump-tests reports wrong name for the second "test_complex" -- libs/tr1/test/test_complex.cpp instead of libs/tr1/test/std_headers/test_complex.cpp I looks like there are two issues in regression system: 1. --dump-tests reports wrong file name 2. The reporting tools don't handle two tests with the same name. Finally, when using Boost.Build V2, instead of above silent issues I get loud complaint right away. So, maybe it's a good idea to add explicit suffix to tests, for example using the following patch: --- Jamfile 12 Dec 2005 18:05:26 -0000 1.10 +++ Jamfile 1 Feb 2006 15:38:17 -0000 @@ -84,7 +84,7 @@ <borland-5_5_1><*><include>$(BOOST_ROOT)/boost/tr1/tr1/bcc32 <borland><*><include>$(BOOST_ROOT)/boost/tr1/tr1/bcc32 <include>$(BOOST_ROOT) - <define>TEST_STD=1 ] ; + <define>TEST_STD=1 : $(file5:B)_header ] ; } Thanks, Volodya
There are three tests reportedly using "test_complex.cpp", and two tests named "tr1/test_complex".
However, regression results at:
http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/tr1.htm...
mention only one test named "test_complex". Further, the first "test_complex" comes from this loop in Jamfile:
for local file in [ GLOB $(BOOST_ROOT)/libs/tr1/test : test*.cpp ] { all_rules += [ compile $(file) : <include>$(BOOST_ROOT) ] ;
and the second "test_complex" comes from this loop:
for local file5 in [ GLOB $(BOOST_ROOT)/libs/tr1/test/std_headers : *.cpp ] { all_rules += [ compile $(file5)
Note that the output of --dump-tests reports wrong name for the second "test_complex" -- libs/tr1/test/test_complex.cpp instead of libs/tr1/test/std_headers/test_complex.cpp
I looks like there are two issues in regression system: 1. --dump-tests reports wrong file name
I suspect this may be the cause of issue #2 as well? Does this mean that two tests with the same name anywhere in Boost will clash? These are in different directories so there really shouldn't be a clash even if there are two files with the same name.
So, maybe it's a good idea to add explicit suffix to tests, for example using the following patch:
Or a prefix like I did for std_ prefixed versions? I'll update the Jamfile. John.
John Maddock wrote:
Note that the output of --dump-tests reports wrong name for the second "test_complex" -- libs/tr1/test/test_complex.cpp instead of libs/tr1/test/std_headers/test_complex.cpp
I looks like there are two issues in regression system: 1. --dump-tests reports wrong file name
I suspect this may be the cause of issue #2 as well?
Maybe.
Does this mean that two tests with the same name anywhere in Boost will clash?
Not "anywhere", but declared in the same Jamfile. Which does not seem so unreasonable, anyway.
These are in different directories so there really shouldn't be a clash even if there are two files with the same name.
The files are in different directory, but both tests are defined in the same Jamfile. At the very least, you won't be able to selectively build one of them.
So, maybe it's a good idea to add explicit suffix to tests, for example using the following patch:
Or a prefix like I did for std_ prefixed versions? I'll update the Jamfile.
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. Thanks, Volodya
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). 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. 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? 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? Whew! Thanks, John.
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
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.
Running setup scripts like that is fine, what was causing me problems were: Compiler include paths injected into the command line with -I *before* the Boost include path (this was VC++ and was in *addition* to running the setup batch file). Library include paths (STLport) injected onto the command line with -I *before* the Boost include path. Hopefully these can be avoided in future, but we'll see I guess :-) John.
participants (2)
-
John Maddock -
Vladimir Prus