
David Abrahams writes:
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
David Abrahams writes:
Martin Wille <mw8329@yahoo.com.au> writes:
It would be nice if we could drop serialization on compilers that just aren't going to work.
Right. I once suggested that this should be implemented for all libraries. Its nonsense to run the tests for libraries which are marked as non-working for certain compilers. This should be a feature of the build system. We don't have that feature, yet. I'm not aware of anyone working on it.
I'd be willing to try, but I think we might get more bang-for-the-buck if I set things up so that failed tests don't run until they're outdated.
That won't help with clean runs, though, and it would be really wonderful to have them speed up a little.
OK.
That part can be done entirely within Boost.Build rather than trying to figure out how to combine some XML markup with it...
I think duplicating markup in Jamfiles or, preferrably, near them (in some form) won't be too bad. E.g., in the library "test" directory we could have a simple "unusable-tools.jam" which could go like this:
unusable-tools = borland-5.5.1 msvc msvc-stlport ;
If we can do something like that, it's even not necessarily a duplication -- for XSL reports, we can always walk through the library directories, collect the markup and transform it into an XML for later processing. In fact, we already to something like this anyway.
unless something in the Jamfile that causes the test to be skipped for certain toolsets is enough for you.
It's the opposite -- a toolset marked as unusable should be skipped.
What does it mean for the toolset to be marked,
Sorry, imprecise wording. Of course it's the library that is marked as unusable with a particular toolset.
and how does it differ from what I suggested?
You seemed to imply that it's skipping of individual tests for particular toolsets that is of our interest. I was trying to make a point that the most important use case is to mark the whole library's *test suite* as unusable. May be from implementation standpoint there is no difference -- but since I have no idea, I thought I'd point it out. -- Aleksey Gurtovoy MetaCommunications Engineering