usage_variants.qbk 4.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102
  1. [/
  2. / Copyright (c) 2003 Boost.Test contributors
  3. /
  4. / Distributed under the Boost Software License, Version 1.0. (See accompanying
  5. / file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
  6. /]
  7. [section:usage_variants Usage variants]
  8. The __UTF__ supports three different usage variants:
  9. # [link boost_test.usage_variants.single_header The header-only variant]
  10. # [link boost_test.usage_variants.static_lib The static library variant]
  11. # [link boost_test.usage_variants.shared_lib The shared library variant]
  12. In most cases you shouldn't have problems deciding which one to use, since there are
  13. clear reasons why would you prefer each one. Following sections should help you with the decision.
  14. [/ ##################################################################### ]
  15. [h3:single_header Header-only usage variant]
  16. If you prefer to avoid the compilation of standalone library, you should use the
  17. header-only variant of the __UTF__. This variant only requires you to include
  18. the unique header: `#include <boost/test/included/unit_test.hpp>`
  19. and there is no need to link with any library. There are several ways to perform
  20. the initialization, but the simplest way is the following:
  21. ``
  22. #define __BOOST_TEST_MODULE__ test module name
  23. #include <boost/test/included/unit_test.hpp>
  24. ``
  25. __BOOST_TEST_MODULE__ macro needs to be defined *before* the include and should indicate
  26. the name of the test module. This name can include spaces and does not need to be wrapped in quotes.
  27. [link boost_test.adv_scenarios.single_header_customizations This section]
  28. gives additional details on how to customize this usage variant. In particular,
  29. it is possible to have several compilation units with this variant, as explained in the section
  30. [link boost_test.adv_scenarios.single_header_customizations.multiple_translation_units Header-only with multiple translation units].
  31. [/ ##################################################################### ]
  32. [h3:static_lib Static library usage variant]
  33. For most users, who has an access to pre-built static library [footnote these files are distributed
  34. with the packaging systems on Linux and OSX for instance] of the __UTF__ or can
  35. [link boost_test.adv_scenarios.build_utf build it] themselves, following usage can be most versatile
  36. and simple approach. This usage variant entails two steps.
  37. # First, the following line needs to be added to all translation units in the test module:
  38. ``
  39. #include <boost/test/unit_test.hpp>
  40. ``
  41. One and *only one* translation unit should include following lines:
  42. ``
  43. #define __BOOST_TEST_MODULE__ test module name
  44. #include <boost/test/unit_test.hpp>
  45. ``
  46. __BOOST_TEST_MODULE__ macro needs to be defined *before* the include and should indicate the
  47. name of the test module. This name can include spaces and does not need to be wrapped in quotes.
  48. # The second step is to link with the __UTF__ *static* library.
  49. [note Header `<boost/test/unit_test.hpp>` is an /aggregate/ header: it includes most of the other headers that contains the Unit Test Framework definitions.]
  50. The flip side of this usage variant is that each test module following this usage variant is going
  51. to be statically linked with __UTF__, which might be something you want to avoid (to save space
  52. for example). For more information about these configuration options check
  53. [link boost_test.adv_scenarios.static_lib_customizations this section].
  54. [/ ##################################################################### ]
  55. [h3:shared_lib Shared library usage variant]
  56. In the project with large number of test modules the static library variant of the __UTF__ may
  57. cause you to waste a lot of disk space. The solution is to link test module dynamically with the
  58. __UTF__ built as a shared library.
  59. This usage variant entails two steps.
  60. # First you need to add following lines to all translation units in a test module:
  61. ``
  62. #define __BOOST_TEST_DYN_LINK__
  63. #include <boost/test/unit_test.hpp>
  64. ``
  65. and *only one* translation unit should include following lines
  66. ``
  67. #define __BOOST_TEST_MODULE__ test module name
  68. #define __BOOST_TEST_DYN_LINK__
  69. #include <boost/test/unit_test.hpp>
  70. ``
  71. `BOOST_TEST_MODULE` and `BOOST_TEST_DYN_LINK` macros needs to be defined *before* the include.
  72. `BOOST_TEST_MODULE` should be set to test module name. This name can include spaces and does
  73. not need to be wrapped in quotes.
  74. # The second step is to link with the __UTF__ *shared* library.
  75. The flip side of this usage variant is that you will need to make sure the __UTF__ shared library
  76. is accessible at runtime to a test module.
  77. In addition shared library usage variant facilitates custom test runners. For more information about this
  78. check [link boost_test.adv_scenarios.shared_lib_customizations this section].
  79. [caution On Windows, the test module and the __UTF__ shared library should link to the same CRT. Not doing
  80. so (for instance __UTF__ shared library in /release/ mode while the test module is in /debug/) will
  81. lead to crashes.]
  82. [endsect] [/Usage Variants]
  83. [/ EOF]