Any time one considers using a library as large and complex as the Boost libraries, he must have a way of validating the the library functions in his environment. This should be done when the library is installed and anytime questions are raised regarding its applicabililty and/or its usage.
The procedures described here permit a user to run any combination of tests on a library and generate a set of convenient tables which show which tests under what conditions.
    Generating these tables requires a couple of utility programs:
    b2
    to run the tests themselves and
    library_status
    which processes the tests and builds the tables. To build
    b2
    consult the documentation for Boost Build. And to build
    library_status
    move to the directory
    
      regression-root/build
    
    and invoking
    b2
    . If all goes well the
    library_status
    executable can be found at
    
      regression-root/stage/bin/library_status
    
    .
  
library_status.
    There should appear a table similar to the following for the regex library.
| Test Name | msvc-7.1 | |||
| debug | release | |||
| link-static | threading-multi | link-static | threading-multi | |
| threading-multi | threading-multi | |||
| bad_expression_test | Missing | Warn | Missing | Warn | 
| captures | Missing | Fail | Missing | Fail | 
| captures_test | Missing | Warn | Missing | Warn | 
| concept_check | Missing | Pass | Missing | Pass | 
| icu_concept_check | Missing | Pass | Missing | Pass | 
| object_cache_test | Missing | Warn | Missing | Warn | 
| posix_api_check | Missing | Warn | Missing | Warn | 
| posix_api_check_cpp | Missing | Pass | Missing | Pass | 
| recursion_test | Missing | Warn | Missing | Warn | 
| regex_config_info | Missing | Pass | Missing | Pass | 
| regex_dll_config_info | Missing | Pass | Missing | Pass | 
| regex_regress | Pass* | Missing | Pass* | Missing | 
| regex_regress_dll | Missing | Pass* | Missing | Pass* | 
| regex_regress_threaded | Missing | Pass | Missing | Pass | 
| static_mutex_test | Missing | Pass | Missing | Pass | 
| test_collate_info | Missing | Warn | Missing | Warn | 
| unicode_iterator_test | Missing | Warn | Missing | Warn | 
| wide_posix_api_check_c | Missing | Warn | Missing | Warn | 
| wide_posix_api_check_cpp | Missing | Warn | Missing | Warn | 
This table was generated by invoking the following command line:
    
      regression-root/stage/bin/library_status --b2 b2
      --boost-root=../../.. toolset=msvc-7.1 variant=debug,release
    
  
from within the boost-root/libs/regex/test directory.
    This table shows the regex test results for both debug and release versions
    of the library. Also it displays the fact that one of the tests is run
    specifically with the static linking/multi-threading versions of the runtime
    libraries. The cells marked "Missing" correspond to tests that were not run
    for some reason or another. This is usually because the corresponding
    Jamfile.v2
    excludes this test for the given combination of compiler and build
    attributes. In this example, all tests were run with the same compiler. If
    additional compilers were used, they would appear as more columns in the
    table.
  
The table above is just an illustration so the links don't actually point to anything. In the table you generated, the links will display a page describing any errors, warnings or other available information about the tests. If the test passes, usually, there is no additional information and hence no link.
    The tables are cumulative. That is, if you run one set of tests now and
    tests with different attributes later, the table will contain all the
    results to date. The test results are stored in
    ../bin.v2/libs/test/<library>/...
    . To reinitialize the test results to empty, delete the corresponding files
    in this directory.
  
    The procedure above assumes that the table are generated within the
    directory
    ../libs/<library>/test
    . This is the most common case since this directory contains the
    Jamfile.v2
    as well as the source code that is used by official boost testers. However,
    this is just a convention. The table can be generated for other directories
    within the libary. One possiblity would be to generate the table for all the
    examples in
    ../libs/<library>/example
    . Or one might have a special directory of performance tests which take a
    long time to run and hence are not suitable for running by official boost
    testers. Just remember that library status table is generated in the
    directory from which the
    library_test
    command is invoked.
  
Copyright 2011 Bryce Lelbach.
Copyright 2007-2011 Robert Ramey.
Copyright 2015 Rene Rivera.
Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or http://www.boost.org/LICENSE_1_0.txt)