Re: [boost] Testing -fno-rtti builds (was:[function]function_base.hpp:220: error: cannot use typeidwith -fno-rtti)

Subject: Re: [boost] Testing -fno-rtti builds (was:[function]function_base.hpp:220: error: cannot use typeidwith -fno-rtti)
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-01-08 15:52:28

Emil Dotchevski wrote:
> On Thu, Jan 8, 2009 at 11:15 AM, Robert Ramey <ramey_at_[hidden]> 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