Re: [Boost-build] Convenient use of build and test semaphores

Subject: Re: [Boost-build] Convenient use of build and test semaphores
From: Matthew Chambers (matt.chambers42_at_[hidden])
Date: 2010-09-23 13:48:27

> Hi,
>
> I have a moderately large project with several hundred files and a couple hundred unit tests. We usually
> build on quad core machines with -j4. Some of our tests
> are I/O intensive and these should not run in parallel. We also have heuristic tests for thread-safety
> which are usually only effective when running alone
> (certainly not at the same time as any other thread-safety tests). The other tests run just fine in
> parallel. I don't think my case could be very unusual either.
>
> So is there a good reason that the JAM_SEMAPHORE built-in is a pain in the ass to use (i.e. only usable on
> actualized targets AFAIK)? Shouldn't we be able to
> specify one or more optional semaphores as build requirements? There could be both build-time semaphores
> and runtime semaphores. The test semaphores would only
> apply at runtime (i.e. the unit-test and capture-output actions in testing.jam).
>
> -Matt

Any input on this? I implemented it myself as a feature in testing.jam (<testing.semaphore>) and it seems to work great. The only remaining issue is some of my 
tests are both I/O and thread intensive, so I need them to have two semaphores instead of one. Will JAM_SEMAPHORE work with multiple values?

But I'm not sure how to implement the build-time semaphores.

-Matt