Re: [boost] Re: Regression Tests, Boost.Serialization

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2004-07-22 19:30:18

David Abrahams writes:
>>> 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.

So, if I, let's say, want to skip algorithm/minmax test suite:

subproject libs/algorithm/minmax/test ;

# bring in rules for testing
import testing ;

# Make tests run by default.
DEPENDS all : test ;

{
  test-suite algorithm/minmax 
        : [ run
                minmax_element_test.cpp
              : :
                :
                : minmax_element
            ]
          [ run
                minmax_test.cpp
              : :
                :
                : minmax
            ]
  ;
}

for "msvc", what do I put where?

>
> 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.

Super, and thank you!

-- 
Aleksey Gurtovoy
MetaCommunications Engineering