Boost.Test - problems overriding main - Boost-users

2 Sep 2015


      I want to provide my own main function while using Boost.Test. So I have included the following macros:
    #define BOOST_TEST_ALTERNATIVE_INIT_API    #define BOOST_TEST_NO_MAIN
In my main function I have a call to: 
    ::boost::unit_test::unit_test_main(®istering_all_tests, argc, argv)
but this gives me the following error when build on OS X using Xcode 6: 
    Undefined symbols for architecture x86_64:      "boost::unit_test::unit_test_main(bool (*)(), int, char**)", referenced from:          _main in main.o
I found out that including the following file:
    #include 
resolves this problem but I'm confused about the implications. The description of this file states that it uses the included (vs. linked) version of Unit Test Framework.
The Boost getting started guide states that:
...
Boost.Test can be used in “header-only” or “separately compiled” mode,> although **separate compilation is recommended for serious use**.
I have built the library separately.
The Boost doc also states:
Including the UTF directly into your test module> > If you prefer to avoid the standalone library compilation you can> either include all files that constitute the static library in your> test module's makefile or include them as a part of a test module's> source file. To facilitate the later variant the UTF presents the> single-header usage variant. In either case no special build options> or macro definitions are required to be added to your compilation> options list by default. But the same flags that can be used for the> standalone library compilation are applicable in this case. Though,> obviously, neither BOOST_TEST_DYN_LINK nor BOOST_TEST_NO_LIB are> applicable. This solution may not be the best choice in a long run,> since it requires the UTF sources recompilation for every test module> you use it with and for every change of a test module you are working> on. In a result your testing cycle time may increase. If it become> tiresome, I recommend switching to one of the prebuilt library usage> variants.
It seems that by choosing to include the included (vs. linked) version of Unit Test Framework I am dong the wrong thing.
Can someone please clarify the correct approach. The examples of overriding main don't mention the need to do this.

Boost.Test - problems overriding main

ramonpadilla1＠yahoo.co.uk

Gennadiy Rozental

ramonpadilla1＠yahoo.co.uk

Gennadiy Rozental

ramonpadilla1＠yahoo.co.uk

tags

participants (2)