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? Comments? - Volodya
On Sat, Mar 14, 2009 at 10:16 PM, Vladimir Prus <ghost@cs.msu.su> 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?
Comments?
Perhaps we can document and say "add -q to the bjam invocation if you want the build to stop on the first error". Although I agree this would be nice to have as the default behavior. -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com
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?
Comments?
I think the best way to do it is to provide a command line switch. Personally, I'd like to see all errors from one build attempt since bjam starts way longer than other build tools. But I understand that the other way around may also be desirable.
AMDG Andrey Semashev wrote:
Vladimir Prus wrote:
So, how about we do what the rest of the world does, and stop build of C++ Boost on the first error?
I think the best way to do it is to provide a command line switch.
There already is such a switch. The question is about the default.
Personally, I'd like to see all errors from one build attempt since bjam starts way longer than other build tools. But I understand that the other way around may also be desirable.
In Christ, Steven Watanabe
On 14/03/2009, Vladimir Prus wrote:
Comments?
Stop on error should be the default behaviour when building. There should also be an option to ignore errors especially for the transition period as it will take time for fixes to the build system to be applied given the large number of combinations of platforms, compilers and options. --Steven
Vladimir Prus:
So, how about we do what the rest of the world does, and stop build of C++ Boost on the first error?
It seems to me that this only works well if a typical bjam invocation is considered an all or nothing proposition. This is not true for running tests, when there are expected failures, and it may well not be true for building Boost on "non-release" platforms, where some libraries may fail to build. It obviously is true for projects where the final target depends on everything else, but Boost is not such a project.
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?
Two comments here: 1) I'm presently using a "compile" test to decide whether some other targets should be built or not - I'd like something like this to continue to be available - preferably as a proper "configure" target. I believe the serialization lib is doing something similar too. 2) We shouldn't stop building lib X just because lib Y doesn't build (when installing Boost). Users of less umm.. versatile.. compilers shouldn't have the whole build stop just because they can't build some of the more "heavyweight" parts of Boost. So while the behavior takes a bit of getting used to - it does have it's uses. Regards, John.
John Maddock 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?
Two comments here:
1) I'm presently using a "compile" test to decide whether some other targets should be built or not - I'd like something like this to continue to be available - preferably as a proper "configure" target. I believe the serialization lib is doing something similar too. 2) We shouldn't stop building lib X just because lib Y doesn't build (when installing Boost). Users of less umm.. versatile.. compilers shouldn't have the whole build stop just because they can't build some of the more "heavyweight" parts of Boost.
So while the behavior takes a bit of getting used to - it does have it's uses.
Well, it has it's uses, but the burden of explaining this behaviour is on us. If default behaviour is stop on error, then users who want something else can look up the doc for the proper switch. - Volodya
Hi Volodya, On Saturday 14 March 2009, Vladimir Prus wrote:
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?
Please don't change this. Or at least provide a ways to configure the default in user-config/site- config.jam. It was/is annoying to have to remember to type "make -i" when hunting errors or doing massive refactorings. It is one of the features I like on (b)jam :-)) Especially if you use a build farm and don't have to wait over lunch ;-)) Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
Juergen Hunold wrote:
Hi Volodya,
On Saturday 14 March 2009, Vladimir Prus wrote:
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?
Please don't change this. Or at least provide a ways to configure the default in user-config/site- config.jam. It was/is annoying to have to remember to type "make -i" when hunting errors or doing massive refactorings. It is one of the features I like on (b)jam :-)) Especially if you use a build farm and don't have to wait over lunch ;-))
This will be configurable, of course, and you will be able to specify the option in *-config.jam files. I might not even change the default. - Volodya
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
Dear boost developers, I checked the implementation of boost::dynamic_bitset::count and find that it uses a table look up. This is not optimal. First on 64-bit machines divide-and-conquer algorithms are faster than table look up and save even memory. Second if the bitset contains several words, there are for both 32 and 64 bit machines population count algorithms that are faster than the simple loop over all words used by boost. Together with Y. Edel I developed a new version,which saves 60% against the simple algorithm. We put the code online (http://cage.ugent.be/~klein/popc.html). A disadvantage of our implementation is that we relay on aggressive optimization (-O3) of the compiler. If you are searching a compromise between speed and code complexity. The first iteration of the Harley-Seal-method (25% faster than the simple loop) would be a candidate. You find this and other population count algorithms on our homepage, too. If there is interest I can add one of the advance algorithms in boost. Best wishes Andreas Klein
Andreas Klein-5 wrote:
Dear boost developers,
I checked the implementation of boost::dynamic_bitset::count
and find that it uses a table look up.
This is not optimal.
First on 64-bit machines divide-and-conquer algorithms are faster than table look up and save even memory.
Second if the bitset contains several words, there are for both 32 and 64 bit machines population count algorithms that are faster than the simple loop over all words used by boost.
Together with Y. Edel I developed a new version,which saves 60% against the simple algorithm. We put the code online (http://cage.ugent.be/~klein/popc.html). A disadvantage of our implementation is that we relay on aggressive optimization (-O3) of the compiler.
If you are searching a compromise between speed and code complexity. The first iteration of the Harley-Seal-method (25% faster than the simple loop) would be a candidate.
You find this and other population count algorithms on our homepage, too.
If there is interest I can add one of the advance algorithms in boost.
Best wishes Andreas Klein
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Please, post on a new thread. Do not replay to existing thread with message not related to. Thanks, Vicente -- View this message in context: http://www.nabble.com/Stop-on-first-error-tp22513100p22539926.html Sent from the Boost - Dev mailing list archive at Nabble.com.
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
Vladimir Prus wrote:
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.
We have some scripts that might be reasonable starting points. They work on Windows, Linux and Macs. There are bits of them that are decidedly hackish though :( svn co http://svn.felspar.com/external/Boost/ They work in such a way that multiple versions of Boost can be used side by side by a number of projects that sit in sibling directories to where you check out Boost. The Jamroot for Boost brings in the libraries as pre-built targets so the Boost source files (which don't change) don't have to be scanned for changes. The mechanism it uses for this is a nasty kludge, but I think the idea is sound as it massively improves build times. K -- http://www.kirit.com/
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?
Comments?
+1. Strongly.
participants (14)
-
Andreas Klein -
Andrey Semashev -
Dean Michael Berris -
Ilya Sokolov -
Johan Nilsson -
John Maddock -
Juergen Hunold -
Kirit Sælensminde -
Peter Dimov -
Steven Solie -
Steven Watanabe -
Vicente Botet Escriba -
Vladimir Prus -
Vladimir Prus