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? / Johan