[Boost-users] Boost.Test - problems overriding main

[ramonp...@yahoo.co.uk]

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(&registering_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 <boost/test/included/unit_test.hpp>

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.

[Gennadiy Rozental]

<ramonpadilla1 <at> yahoo.co.uk> writes:

>
>
>
> I want to provide my own main function while using Boost.Test.

Please take a look at new docs for detailed explanation on this subject
with examples.

> So I have included the following macros:
>
>     #define BOOST_TEST_ALTERNATIVE_INIT_API
>     #define BOOST_TEST_NO_MAIN
>

> 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

This is because your library was built without
BOOST_TEST_ALTERNATIVE_INIT_API.

>
> I found out that including the following file:
>
>     #include <boost/test/included/unit_test.hpp>

Single header version will work indeed.

>
> resolves this problem but I'm confused about the implications.

Your only implication is that you will have to spend a bit more time on
compilation (maybe negligible, if you have enough power) and you have to
stick with single file test modules.

_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[ramonp...@yahoo.co.uk]

>________________________________
> From: Gennadiy Rozental <rog...@gmail.com>
>To: boost...@lists.boost.org
>Sent: Wednesday, 2 September 2015, 19:48
>Subject: Re: [Boost-users] Boost.Test - problems overriding main

>
>
><ksl <at> yahoo.co.uk> writes:
>
>>
>> I want to provide my own main function while using Boost.Test.
>
>Please take a look at new docs for detailed explanation on this subject
>with examples.

OK.

>> So I have included the following macros:>>
>> #define BOOST_TEST_ALTERNATIVE_INIT_API
>> #define BOOST_TEST_NO_MAIN
>>
>> 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
>
>This is because your library was built without BOOST_TEST_ALTERNATIVE_INIT_API.

Having looked at the documentation, it suggests that I only need to build the library with BOOST_TEST_NO_MAIN if I want to supply my own main. Why do I also need to also build with BOOST_TEST_ALTERNATIVE_INIT_API?

>>
>> I found out that including the following file:
>>
>> #include <boost/test/included/unit_test.hpp>
>

>Single header version will work indeed.

I'm not sure I understand. Can you elaborate?

>>
>> resolves this problem but I'm confused about the implications.
>
>Your only implication is that you will have to spend a bit more time on
>compilation (maybe negligible, if you have enough power) and you have to
>stick with single file test modules.

Again, can you please elaborate?

And just to clarify, if I want to provide my own main function, I *must* build the library with at least BOOST_TEST_NO_MAIN. Under what circumstances would I also build it with BOOST_TEST_ALTERNATIVE_INIT_API?

[Gennadiy Rozental]

<ramonpadilla1 <at> yahoo.co.uk> writes:

> >This is because your library was built without
BOOST_TEST_ALTERNATIVE_INIT_API.
>
> Having looked at the documentation, it suggests that I
> only need to build the library with
> BOOST_TEST_NO_MAIN if I want to supply my own main. Why do
> I also need to also build with BOOST_TEST_ALTERNATIVE_INIT_API?

Why did you specify it in your test module?

The value of this macro should be the same both during library build and
when you build test module.

> >>
> >> I found out that including the following file:
> >>
> >> #include <boost/test/included/unit_test.hpp>
> >
>
> >Single header version will work indeed.
>
> I'm not sure I understand. Can you elaborate?

Single header version build both framework and your test module
simultaneously. Obviously this resolved the issue with discrepancy in
BOOST_TEST_ALTERNATIVE_INIT_API value.

> >> resolves this problem but I'm confused about the implications.
> >
> >Your only implication is that you will have to spend a bit more time on
> >compilation (maybe negligible, if you have enough power) and you have
to
> >stick with single file test modules.
>
> Again, can you please elaborate?

What specifically you want me to elaborate on? Single header might take a
bit more time to build and only allow you to use one test file per test
module.

>
> And just to clarify, if I want to provide my own main function,
> I *must* build the library with at least
> BOOST_TEST_NO_MAIN.

If you are building static library - yes.

> Under what circumstances would I also build it with
> BOOST_TEST_ALTERNATIVE_INIT_API?

It is up to you. You need to make sure you set the same value when you
build library and test module.

[ramonp...@yahoo.co.uk]

>________________________________
> From: Gennadiy Rozental <rog...@gmail.com>
>To: boost...@lists.boost.org

>Sent: Monday, 7 September 2015, 6:39

>Subject: Re: [Boost-users] Boost.Test - problems overriding main
>
>

><ramonpadilla1 <at> yahoo.co.uk> writes:
>
>> >This is because your library was built without
>BOOST_TEST_ALTERNATIVE_INIT_API.
>>
>> Having looked at the documentation, it suggests that I
>> only need to build the library with
>> BOOST_TEST_NO_MAIN if I want to supply my own main. Why do
>> I also need to also build with BOOST_TEST_ALTERNATIVE_INIT_API?
>
>Why did you specify it in your test module?
>
>The value of this macro should be the same both during library build and

>when you build test module.

OK. I get it now thanks.