Emil Dotchevski wrote:
On Thu, Jan 8, 2009 at 11:15 AM, Robert Ramey <ramey@rrsd.com> wrote:
Users should be encourged to run the tests when they install and report any issues. This should be part of the installation procedure.
That's a good idea provided that the tests run automatically (allowing an opt-out.)
I would be a little less insistent - Just upgrading the documentation to suggest that running the tests/demos is a normal part of every software installation and boost is no exception.
The problem I suppose is that most users simply download the binaries. The mostly header-only nature of Boost also encourages this behavior. I don't blame them, it isn't trivial to get the build up and running.
This is indeed the main obstacle. Thinking about this a little more - maybe it's not so bad. My personal procedure for dealing with boost is exemplified with the library_test shell script/bat files and library_test executable which are already part of boost. I realize that they ar not widely used (if at all) by anyone other than myself - but I think they should be. These are very "thin" scripts and one executable. When I run this script from within any lib/<library name>/test, the following happens. a) bjam is invoked for the tests in the library. b) following bjam rules, all dependent libraries are built c) the libraries tests are run. d) a browsable html test results table is built in the lib/<library name>/test directory. I would like to see this developed into the "officially suggested" boost way of doing things. This would have the following advantages: a) build would be faster for those only using a few libraries. Currently, the build time is constantly increasing since boost itself is constantanly getting bigger. That is, the current build doesn't scale. b) Tests would be automatically run in the users environment. Only those tests relevant to the particular user would actually be run. c) It leverages on current boost procedures - i.e. bjam. d) I would help move boost in the direction of "a collection of orthogonal libraries" rather than "a collection of interdependent libraries". Boost is and should be the former, but the tools (monilithic giant build, install and test, monilithic documentation build, etc. suggest the latter. Robert Ramey