From: David Abrahams (dave_at_[hidden])
Date: 2004-07-22 09:09:21
Aleksey Gurtovoy <agurtovoy_at_[hidden]> writes:
> David Abrahams writes:
>> Martin Wille <mw8329_at_[hidden]> 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