Re: [boost] Boost.Tests: Unit test defines own main() function, why?

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2007-12-24 13:47:29

"Ilya Sokolov" <fal_delivery_at_[hidden]> wrote in message 
news:fko5dv$g8l$1_at_ger.gmane.org...
> Gennadiy Rozental wrote:
>> "Ilya Sokolov" <fal_delivery_at_[hidden]> wrote in message
>> news:fkg1cd$gdv$1_at_ger.gmane.org...
>>> Sorry for breaking into discussion but I have a bunch of related
>>> questions.
>>>
>>> Gennadiy Rozental wrote:
>>>> "Jens Seidel" <jensseidel_at_[hidden]> wrote in message
>>> [snip]
>>>> Because BOOST_TEST_MAIN produces both function main and empty init
>>>> function.
>>>> It's assumed that test units are automatically registered.
>>> Why both? Also, why defining BOOST_TEST_DYN_LINK switches on
>>> BOOST_TEST_ALTERNATIVE_INIT_API?
>>
>> 1. Because alternatively I would've required 90% of the users to define 2
>> pretty closely names macro: BOOST_TEST_MAIN to define init function (this 
>> is
>> what this macro always did, so I can't change the meaning)
>
> In my opinion, BOOST_TEST_MAIN is a misleading name because it produces
> not only the main() function.

It is a bit. Now. But you should understand the history. First of all this 
macro primary puspose is to produce init function (not function main(), so 
you got quite the opposite "because"). Initially test module init function 
was considerred a replacement for the function main(), since the fnction 
main itself was part of the library. And BOOST_TEST_MAIN was intended to 
generate empty one.
Later on during dynamic library support update it functionality was 
increased t oactually produce the function main(). I don't see ths as a big 
problem. In most cases it's still clear what it means - it designate test 
file as containing test module entry point.

>> plus another one
>> BOOST_TEST_MAIN_FUNCTION that will actually produce the function main()
>
>> 2. Unfortunately original test modult function signature is unacceptable 
>> for
>> DLL initialization. So i had to introduce new one.
>
> I don't see it unacceptable, given the majority of
> init_unit_test_suite() functions using BOOST_TEST_SUITE macro. I think

See my other post. It has nothing to do with BOOST_TEST_SUITE macro

> BOOST_ALTERNATIVE_INIT_API should be default, but not the requirement
> for dynamic builds. And maybe it should be default for static builds
> also, because now it is recommended to use "master test suite".

Quite the opposite: I can't be default and it is a requirement for the 
dynamic builds. And again it has nothing to do with master test suite 
interface.

>>> Suppose I need to perform some initialization call, e.g.
>>> boost::filesystem::initial_path(). Currently, with shared Boost.Test I
>>> am forced to not to define BOOST_TEST_MAIN and to copy/paste the main()
>>> function like this:
>>>
>>> int BOOST_TEST_CALL_DECL main(int argc, char* argv[])
>>> {
>>>     return boost::unit_test::unit_test_main(&init_unit_test, argc, 
>>> argv);
>>> }
>> No. I don't think this is the best approach. Much better (and shorter)
>> solution is
>>
>> struct init {
>>     init() { boost::filesystem::initial_path(); }
>> }
>>
>> BOOST_GLOBAL_FIXTURE( init );
>
> I see this much cleaner:
>
> #ifdef BOOST_TEST_DYN_LINK
> # define BOOST_TEST_MAIN_FUNCTION
> #endif

Where this maro is used?

> #include <boost/test/unit_test.hpp>
>
> bool init_unit_test()
> {
>   boost::filesystem::initial_path();
>   return true;
> }

What if you need to to some cleanup as well? What if you need to do multiple 
initialization bits that reside in different test files? What if all your 
test units are automatically registerred - init function definition will 
require function main as well if you intend to use shared library.

>>> Now if I want to support using static Boost.Test, I am forced to define
>>> BOOST_TEST_ALTERNATIVE_INIT_API.
>>
>> I always find it confusing: why would you want to support both static and
>> shared libraries?
>
> Why not???

Why yes?? From my prospective it's misgueded effort, sinse most of the time 
you select one usage fariant and stick with it.

>> Pick one more convinient for you and stick with it. It's
>> not like you need to test your test module with all variants of 
>> Boost.Test
>> framework. It's your own test, not the test for the UTF. All in all I 
>> find
>> an effort for simultanious support for both static and shared variant of 
>> the
>> UTF a bit misguided.
>
> I want to seamlessly migrate from static UTF to shared. I need to
> fallback to the static UTF where it is not supported (by toolchain).

Where? The primary direction of my effort was to make sure shared library 
works consistently on all platforms. If you still insist on static/shared 
library compartibility it can be achieved: define BOOST_TEST_NO_MAIN and 
BOOST_TEST_ALTERMNATIVE_INIT_API during library compilation and you got what 
you need.

Genadiy