David Abrahams wrote:
on Sun Jul 29 2007, Edward Diener <eldiener-AT-tropicsoft.com> wrote:
We all know it's a problem, but nobody has yet designed and implemented a solution. Perhaps you'd be willing to take up the charge?
Well, I have the same problem. Here is what I'm doing to address it. I'm making some shell scripts to run the boost build / test on the current configuration. This is basically a slightly modfied/updated version of runtest.sh (written by Rene Rivera) found in the tools/regression directory. The object of this new script isn not to download and test the latest version in the CVS system on the local environment. Its aim will be to validate the current boost installation by running all the test and generated a local table - similar to the compiler status table. This gives me what I need. That it is it tells me that the local combination of boost version, libraries, compiler and operating system works (or does not work) as it should. I believe that every user of boost in a production environmentment should undergoe this process. (Actually, a similar process should be undertaken with all software. Commercial software usually includes a series of tests and demos that the user can can run to verify that everything works as it is expected to. I need this now because I have a customer with several platforms with different combinations of os/compiler versions. Its unrealistic to expect that boost testing process to produce such information. Even if it did - there is no guarentee the the test conditions are identical. Robert Ramey