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, and how does it differ from what I suggested? I've just checked in changes as follows: To disable building any target, add <build>no to its requirements. Obviously, you'd want to do that with a qualified requirement, something like <msvc><*><build>no You can also use rule names in requirement lists, for example: rule disable-intel ( toolset variant : requirements ) { if [ MATCH ([Ii]ntel) : $(toolset) ] { requirements += <build>no ; } return requirements ; } exe foo : foo.cpp : disable-intel <define>FOO ; run my-test.cpp : : : disable-intel ; That sort of matching is likely to be more useful for our tests. If you supply --dump-unbuilt on the command-line, Boost.Build will write a line like **** skipping build of $(target); toolset= $(toolset) variant= $(variant) **** ; For each explicitly-skipped target. HTH, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com