[boost] Re: Regression Tests, Boost.Serialization

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