Boost logo

Boost :

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.


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


to its requirements. Obviously, you'd want to do that with a
qualified requirement, something like


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.


Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at