Re: [boost] Stop on first error

Subject: Re: [boost] Stop on first error
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2009-03-17 15:24:37

Johan Nilsson wrote:

> Vladimir Prus wrote:
>> Presently, when building Boost, the build process does not stop if an
>> error has occurred. This is behaviour we inherited, and it differs
>> from every
>> other build system out there. We had quite a number of users confused
>> where build ends with "failed N targets", with the original error
>> scrolled away -- it is not apparent what has caused the error, and
>> often, the error is not even available from console program history.
>>
>> While experienced users might prefer being able to kick a build, go
>> to lunch, and then fix a couple of failures in the middle of the
>> build, ordinary users don't like it so much. So, how about we do what
>> the rest of the world does, and stop build of C++ Boost on the first
>> error?
> 
> I personally use bjam's "-q" switch for at least 90% of my bjam invocations
> when I work interactively with the code. The other 10% or so occurs e.g.
> when I perform a parallell full/clean build of some of our projects that
> include some volatile functional testing (timing-sensitive tests that are
> affected by having the system heavily loaded), in order to "build as much as
> possible as fast as possible". For the latter I usually invoke the build
> using e.g. "bjam -a -jN && bjam -q".
> 
> For the builds on our continuous integration servers we never use the "-q"
> switch, obviously.
> 
> In summary; having the equivalent of "-q" as the default would be preferred,
> but I don't have a very strong opinion about this.
> 
>> Comments?
> 
> Perhaps just using the "-q" switch in all examples in the "Getting Started"
> guide, and strongly recommend "non-advanced" users to always do that, could
> help out here?

In fact, I plan to implement a scripted solution for building C++ Boost using
exactly one command, so I can include -q in that solution. Thanks for suggestion.

- Volodya