Dmitry Moskalchuk wrote:
On 11/05/15 19:09, John Maddock wrote:
The last category of failures (generic "fail") is for the others or unknown. Currently the "Lib" errors are falling into this category. There are some in Math, e.g.: http://www.boost.org/development/tests/develop/developer/output/CrystaX-NET-...
That's a weird one - if you follow the links it actually says that linking the lib succeeded - which leaves me wondering what actually went wrong? Actually there is error "clang: error: cannot specify -o when generating multiple output files" on building pre-compiled header. It's unclear for me why link was done after compile failure; probably there is bug with wrong propagation of exit code or something like that. I'll try to look into that and figure out what's wrong.
I saw also "Lib" errors where the compilation suceeded but linking wasn't mentioned, in the past in Geometry, AFAIR for newly tested compilers. Like those currently reported for Iostreams: http://www.boost.org/development/tests/develop/developer/iostreams.html e.g. see http://www.boost.org/development/tests/develop/developer/output/BenPope%20x8... Now it should be easier to track them. I'm wondering, if this is some bug in Build would it be helpful to detect such issues and mark the tests differently? Of course everything according to the test type - run, compile, compile-fail, etc. For instance: - a "Lib" test mentioning only succeeding phases, e.g. only mentioning succeeding compilation when the test should run, - more general, a test mentioning only some of the phases, so not mentioning the desired phase, - a test with failing previous phases but succeeding next phases, e.g. failing compilation but succeeding linking. Could something like this be helpful? Regards, Adam