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

From: Jens Seidel (jensseidel_at_[hidden])
Date: 2007-12-19 04:02:39

On Tue, Dec 18, 2007 at 03:46:29PM +0000, Gennadiy Rozental wrote:
> Jens Seidel <jensseidel <at> users.sf.net> writes:
> > I would like to know why Boost's unit test framework requires that the
> > user defines init_unit_test_suite(int, char**) (or with char *[]
> > argument???) instead of main().
> 
> It doesn't. At least not always.

OK.
  
> > I recently had again some trouble because of it:
> >  * It broke the general autoconf test in boost.m4 as the existance of
> >    a Boost library can normally easily be tested by using boost code
> >    in main() and not init_unit_test_suite(). (Will probably be fixed
> >    soon in boost.m4.)
> 
> I can't comment on this, since I am not familiar with autoconf.

This is not necessary. I just mentioned that I thought I observed that
instead of an ordinary main() function init_unit_test_suite() needs to
be defined which is just different from normal coding.
 
> >  * According to http://lists.boost.org/Archives/boost/2007/05/121601.php
> >    linkers don't look into libraries (either static or dynamic) to
> >    find main so that unit tests cannot be cimpiled as shared library.
> 
> They do. On *nix platforms you can put main both in shared and static libs. On 
> NT only static. This was a source of inconsistency till 1.34.1, so starting 
> that release I've removed main from shared library builds on all platforms. 

And why are static and shared libraries handled differently? Why not
just removing main also from static libraries? Should code really behave
differently depending how it is linked (which is just a build
configuration)? Do there exist other (non-Boost) libraries which do such
stuff?

> It's not a bug. It's a feature. ;) Starting 1.34.1 main() doesn't reside in 
> shared libs.

Is this change documented? Where can I find the Changelog? Did you also
consider using a stable ABI (application binary interface, would allow a
binary to be used with different library version without need to
recompile) or API (application programming interface, no need to change
the source code to be able to compile against a new version of a
library) (at least some time in the future) which would make
incompatibilities between shared and static libraries impossible and
simplifies using different versions of Boost a lot? Whenever I try
another Boost version existing code fails to compile or link ...

The problem is that the example in the official documentation (which is
(or should be) on www.boost.org not somewhere outside) just contains:
"the Unit Test Framework is responsible for supplying function main()"

Even if you consider that to be outdated (again: Why do you not update
it??????) you should assume that most code arround does not provide
main() and fails that's why starting with recent versions.
  

According to the updated documentation
(http://www.patmedia.net/~rogeeff/html/utf/user-guide/test-runners.html)
using the static library results in

int main(int argc, char* argv[])
{
  return unit_test_main(argc, argv);
}

whereas the shared library uses
int unit_test_main( bool (*init_unit_test_func)(), int argc, char*
argv[] );

How could I define my own main function which is compatible with shared
and dynamic libraries? unit_test_main has different signatures!?

Probably I have to define BOOST_TEST_MAIN and let Boost create main.
Let's hope this works for all linking options (shared/static).

> In any case Boost.Test supports 
> what you want. In many, many cases you don't need init_.. function anymore and 
> boost test provides a way for users to get away without it and function main() 
> as well both with static and shared library usage variant of the UTF. If you 

OK. This is probably preferred.

> prefer to define main youself and invoke init function you can do it as well 
> with shared library variant.

The main problem is that I miss a porting guide. Is there a need to change
the code, are some changes suggested, others required? How do I ensure
that this changed code is compatible with as many versions of Boost as
possible?

I have really problems ignoring
http://www.boost.org/libs/test/doc/components/utf/index.html as I
consider this the offical documentation for Boost.Test. But it
contradicts in some parts with your updated one!

> Please look for more details here:
> 
> http://www.patmedia.net/~rogeeff/html/index.html
> 
> Please let me know if there is any issues still.

Problem with your updated documentation:
http://www.patmedia.net/~rogeeff/html/utf/user-guide/usage-variants/static-lib-variant.html

<quote>
For a test module to be able to link with prebuilt library, the flag
BOOST_TEST_ALTERNATIVE_INIT_API has to be defined both during library
and a test module compilation.
</quote>

Hm, strange. Above I read that I can optionally define
BOOST_TEST_ALTERNATIVE_INIT_API or not. Maybe you want to inform that
BOOST_TEST_ALTERNATIVE_INIT_API needs to be (un)defined for both -
compiling the library and a test module compilation, e.g. it is invalid
to compile the first with this macro defined and the test module
without?

http://www.patmedia.net/~rogeeff/html/utf/user-guide/usage-variants/dynamic-lib-variant.html
<quote>
This variant requires you to define the flag BOOST_TEST_DYN_LINK either
in a makefile or before the header boost/test/unit_test.hpp inclusion.
</quote>

Is there really a need to define BOOST_TEST_DYN_LINK or does it just
simplify linking on the proprietary win32 platform? Again: Why are
static and shared libraries handled differently? It shouldn't matter!

Let me summarize: There is old and new documention which contradict each
other and there is shared ans static code. So I wonder whether it's
possible to work with a single code base.

Jens