Boost.Tests: Unit test defines own main() function, why?

[Jens Seidel]

Hi,

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().

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.)
 * 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.
 * I noticed that Debian's Boost library doesn't work for me as main()
   is not found in the shared library (but in the static one). I found
   now beside my bug report
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456863
   also
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432921
   which mainly refers to the link above.

I'm not sure whether my problem is an error in Debian's packages
or not but I ask why is main handled differently in Boost.test?
Wouldn't it be sufficient to ask the user simple to start
init_unit_test_suite() from a user specified main() to make most
problems go away? Maybe it would be even OK to just start
init_unit_test_suite() in the constructor of a static variable
(yes, I know that the initialisation order may cause trouble with
other static data).

http://www.boost.org/libs/test/doc/faq.html doesn't explain it!

I will now use ifdef's to easily allow using
boost/test/included/unit_test.hpp as alternative to the library.

Jens
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Benoit Sigoure]

On Dec 18, 2007, at 10:50 AM, Jens Seidel wrote:

> Hi,
>
> 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().
>
> 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.)

Hmm I was going to fix this today but now that you're raising this  
issue here, I'll wait to have a better insight of the situation  
before taking action.

--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gennadiy Rozental-2]

Jens Seidel <jensseidel <at> users.sf.net> writes:

>
> Hi,
>
> 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.
 
> 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.

>  * 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 that was the problem in post above (plus the fact that gcc prefers shared
library to static one if both exist with hte same name)

>  * I noticed that Debian's Boost library doesn't work for me as main()
>    is not found in the shared library (but in the static one). I found
>    now beside my bug report
>    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456863
>    also
>    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432921
>    which mainly refers to the link above.

It's not a bug. It's a feature. ;) Starting 1.34.1 main() doesn't reside in
shared libs.
 
> I'm not sure whether my problem is an error in Debian's packages
> or not but I ask why is main handled differently in Boost.test?

See above.

> Wouldn't it be sufficient to ask the user simple to start
> init_unit_test_suite() from a user specified main() to make most
> problems go away?

> Maybe it would be even OK to just start
> init_unit_test_suite() in the constructor of a static variable
> (yes, I know that the initialisation order may cause trouble with
> other static data).

Jens, to be frank with you, I am not quite sure what you are complaining
about: absence of main or presence of one. 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
prefer to define main youself and invoke init function you can do it as well
with shared library variant. Please look for more details here:

http://www.patmedia.net/~rogeeff/html/index.html

Please let me know if there is any issues still.

Genandiy


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Jens Seidel]

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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Jens Seidel]

Hi,

I know it may no longer fit on this list but as I started here let's not
move the list ...

I read most of the new documentation but to make it short: I still fail
to use unit tests. It worked in the past but after a lot of changes
in Boost.Tests it is now unusable for me.

On Wed, Dec 19, 2007 at 10:02:39AM +0100, Jens Seidel wrote:
> On Tue, Dec 18, 2007 at 03:46:29PM +0000, Gennadiy Rozental wrote:
> > Jens Seidel <jensseidel <at> users.sf.net> writes:
> > > 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.)

Benoit: Have fun updating boost.m4.
Additionally you have now to care about incompatible differences in recent
versions, different handling depending on linkage and probably more. It
will be interesting to see you solving this for all possibilities :-)
 
> > >  * 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.
 
> > It's not a bug. It's a feature. ;) Starting 1.34.1 main() doesn't reside in
> > shared libs.
 
> > 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.

But now I wonder why I should make a lot of incompatibles changes? I
want my program and all tests beeing able to compile everywhere with
(nearly) all versions of Boost.

Using some small code parts condionally depending on autotools system
and Boost tests (version of boost, shared library is available?, ...)
would be acceptable but I'm no willing to make major changes to my code.
 
> > prefer to define main youself and invoke init function you can do it as well
> > with shared library variant.

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

I read again carefully the documentation (http://www.patmedia.net/~rogeeff/html)
which exists in parallel to http://www.boost.org/libs/test/doc and can confirm
that the problem that main() is not found still exists!

Including the header boost/test/included/unit_test.hpp *once* per binary seems
to work but normal using of boost/test/unit_test.hpp together with an additional
#define BOOST_TEST_DYN_LINK
still leads to a missing main() function. I get since 1.34.1:
/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crt1.o: In function `_start':
(.text+0x18): undefined reference to `main'
collect2: ld returned 1 exit status

I defined also a dummy main function (just to make the linker happy as I
assumed the tests are maybe started in the contructor of a static variable) but
my test is not called. Even calling init_unit_test_suite() from main() does not
work.

I also defined BOOST_TEST_DYN_LINK on the comandline to ensure that all code
uses it. Same result! Defining addionally BOOST_TEST_MAIN results in a
a proper empty test with the output
 "Test setup error: test tree is empty"
I thought I have also seen a conflict with my own init_unit_test_suite()
implementation if I define BOOST_TEST_MAIN but cannot reproduce it.


A question: Would it be save to define BOOST_TEST_DYN_LINK also for static
linkage? I hope so as I have never, really never used different code depending
on linker options.

Even after renaming my main
test_suite* init_unit_test_suite(int, char *[])
function into
bool init_unit_test()
(but only for dynamic linkage?) as noticed on
http://www.patmedia.net/~rogeeff/html/utf/user-guide/initialization.html
I fail as usual.

Short: In the past it was so simple:

#include <boost/test/unit_test.hpp>
using boost::unit_test::test_suite;
test_suite* init_unit_test_suite(int, char *[])
{
   test_suite *test = BOOST_TEST_SUITE("Master test suite");
   test->add(BOOST_TEST_CASE(&JacobiTest1));
   return test;
}

Now I use

* Additional autoconf code to define HAVE_UNIT_TEST_LIB if the (shared?) library is
  used.

#ifdef HAVE_CONFIG_H
#include <config.h> // HAVE_UNIT_TEST_LIB
#endif

#ifdef HAVE_UNIT_TEST_LIB
#  define BOOST_TEST_DYN_LINK
#  include <boost/test/unit_test.hpp>
#else
#  include <boost/test/included/unit_test.hpp>
#endif

using boost::unit_test::test_suite;

bool init_unit_test()
{
  // my old init_unit_test_suite code
}

/*
int main(int argc, char *argv[])
{
  init_unit_test_suite(argc, argv);
  return 0;
}
*/

I'm now really tired and stoped. A more or less easy to use
library (I had to follow only same advises on
http://www.boost.org/libs/test/doc/components/utf/index.html)
is now more or less unusable. The code depends on the linkage,
the documentation can be found outside of the boost.org domain,
the required information is wrong and incomplete and addionally
scattered across multiple pages such as
http://www.patmedia.net/~rogeeff/html/utf/compilation.html
http://www.patmedia.net/~rogeeff/html/utf/compilation/direct-include.html
http://www.patmedia.net/~rogeeff/html/utf/user-guide/usage-variants.html
 (and all referenced sub pages)
http://www.patmedia.net/~rogeeff/html/utf/user-guide/test-runners.html
http://www.patmedia.net/~rogeeff/html/utf/user-guide/initialization.html

To show you that I really read (at least up to UTF) the documenation I mention
a few errors in it:

http://www.patmedia.net/~rogeeff/html/faq.html:
 * "provide provide"
 * "link with libunit_test_framework.lib"
    that's platform specific!!!
 * "The reasons for this error is that in your implementation you should
    specify second argument of init_unit_test_suite exactly as in a
    specification, i.e.: char* []."
   s/as in a specification/as in the specification/ (I first read e.g.
   instead of i.e. which confused me even more, maybe you should avoid "i.e.".)

http://www.patmedia.net/~rogeeff/html/open-issues.html
 * "Finish update for CLA support"
   What is CLA?
 * Remove two or three full stops in the enumeration
 * "Better Unicode support (reports and log in wostream)"
   Sorry, I don't see any relation of wostream and Unicode!
   You mean UTF16 encoding? UTF8 should work fine with both
   ostream and wostream, right?

http://www.patmedia.net/~rogeeff/html/execution-monitor.html
 * "Also The Execution Monitor"
   s/The/the/

http://www.patmedia.net/~rogeeff/html/execution-monitor/reference.html
 * Page misses a "next" link to
   http://www.patmedia.net/~rogeeff/html/boost/execution_exception.html

http://www.patmedia.net/~rogeeff/html/prg-exec-monitor/impl.html
 * Link to libs/test/execution_monitor.cpp does not work
 * "wraps a several system headers"
   s/a//

http://www.patmedia.net/~rogeeff/html/minimal.html
 * "other then include boost/test/minimal.hpp"
   s/include/including/
 * "This approach is are similar" (belongs to folded text for example 4)
   s/are//

http://www.patmedia.net/~rogeeff/html/tutorials/intro-in-testing.html
 * "why testing worth the effort"
   s/testing/testing is/

http://www.patmedia.net/~rogeeff/html/tutorials/new-year-resolution.html
 * s/BOOST_AUTO_EST_CASE/BOOST_AUTO_TEST_CASE/
 * "As a result my test suite became to look like this:"
   Wrong example!!! data_access_test() was expected

http://www.patmedia.net/~rogeeff/html/utf/user-guide/initialization.html
 * "Alternatively in you can employ"
   s/in//
 * "with the static library or single-header variants of the UTF requires the
    specific function specification."
   Check this! s/specification/signature/, s/specific/original/?

Per accident (used wrong browser window) I read also partely the old
documentation:
http://www.boost.org/libs/test/doc/components/utf/index.html
 * s/messy a error/messy error/
 * "The framework" ... "provides function main() that initialize the framework"

   That's wrong!
 * Example file "unit_test_example1.cpp" does not exist on your server (error 404).

Jens
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gennadiy Rozental-2]

"Jens Seidel" <jensseidel@...> wrote in message
news:20071219090237.GA13691@......

>> >  * 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?

1. For backward compartibility
2. For enhanced usebility in many cases. For people producing a lot of unit
tests adding extra function main()
implementation is unnnecessary burdan (not mentioning that they will have to
actually learn how implement it properly.
3. In many (if not the most) cases function main() handling is hidden
completely from the users and usage and both usage variants behave pretty
much the same. The only difference is presence of an extra macro
BOOST_TEST_DYN_LINK.

> 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?

You comming to this from *nix prospecive. On NT dll and lib are two quite
different ball games. Boost.Test opted to be consystent in between
platforms.

>> 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?

In svn I guess.

> 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)

I sugest I write Boost.Test using C? In Boost.Test  a lot of staff happends
in headers. We might find it difficult.

> 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)

I do not plan any changes that should break backward compartibility. 1.34.1
did break it for very small number of use cases, which where never
officially supported in a first place (plus I believe 1 tool was found
unsafe and the interface was changes).

> 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 ...

I am sure we will be able to figure it out. As far as i know there is no
problem compiling/linking Boost.Test.

> 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.

I did. And it deosn't fail for:

1. Users linking with static library
2. Users using included version
3. Users linking shared library and relying on automatic registration.

Only those who employ shared library and manual registration had an issue.
Which is very easily resolve on all the cases.

> 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);
> }

No, that page doesn't say it. You *may* use it like this if you opt, but by
default function main() reside in library and you don't need to implement
one.

> 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!?

1. shared and dynamic libs are comparitble ;)
2. Don't define init function at all. Employ automated registration
facilities. And you don;t need ot care about test runner function signature.
3. The test runner  function signature is now the same for both static and
dyanmic library (see svn). I am yet to update the updated docs ;)

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

It will if you are using autmatic registration facility.

>> 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

In many case no changes are required. It should work as is.

> 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!

Yes, the version on boost.org is very old. Docs writting take as much time
(if not more) as actual development.

>> 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?

I might need to rephrase it. The idea is that if you opted to use
alternative API you neeed to define this flag both during library and test
module compilation.

> 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?

Really, really ;)

> Again: Why are
> static and shared libraries handled differently? It shouldn't matter!

It does on windows.

Gennadiy



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gennadiy Rozental-2]

"Jens Seidel" <jensseidel@...> wrote in message
news:20071220161635.GA515@......
> Hi,
>
> I know it may no longer fit on this list but as I started here let's not
> move the list ...
>
> I read most of the new documentation but to make it short: I still fail
> to use unit tests. It worked in the past but after a lot of changes
> in Boost.Tests it is now unusable for me.

Let's  see concrete examples.

>> > >  * 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.
>
>> > It's not a bug. It's a feature. ;) Starting 1.34.1 main() doesn't
>> > reside in
>> > shared libs.
>
>> > 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.
>
> But now I wonder why I should make a lot of incompatibles changes? I
> want my program and all tests beeing able to compile everywhere with
> (nearly) all versions of Boost.
>
> Using some small code parts condionally depending on autotools system
> and Boost tests (version of boost, shared library is available?, ...)
> would be acceptable but I'm no willing to make major changes to my code.

You shouldn't be required.

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

See example 9 on

http://www.patmedia.net/~rogeeff/html/utf/user-guide/test-organization/manual-nullary-test-case.html

> Including the header boost/test/included/unit_test.hpp *once* per binary
> seems
> to work but normal using of boost/test/unit_test.hpp together with an
> additional
> #define BOOST_TEST_DYN_LINK
> still leads to a missing main() function. I get since 1.34.1:
> /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crt1.o: In function
> `_start':
> (.text+0x18): undefined reference to `main'
> collect2: ld returned 1 exit status

You also need to define either BOOST_TEST_MODULE or BOOST_TEST_MAIN if you
want Boost.Test to generate main function for you. Like in an example 18
here:

http://www.patmedia.net/~rogeeff/html/utf/user-guide/test-organization/master-test-suite.html


> I defined also a dummy main function (just to make the linker happy as I
> assumed the tests are maybe started in the contructor of a static
> variable) but
> my test is not called. Even calling init_unit_test_suite() from main()
> does not
> work.

You need to call a test runner not init function. See example 9 above.

> I also defined BOOST_TEST_DYN_LINK on the comandline to ensure that all
> code
> uses it. Same result! Defining addionally BOOST_TEST_MAIN results in a
> a proper empty test with the output
> "Test setup error: test tree is empty"

Because BOOST_TEST_MAIN produces both function main and empty init function.
It's assumed that test units are automatically registered.

> I thought I have also seen a conflict with my own init_unit_test_suite()
> implementation if I define BOOST_TEST_MAIN but cannot reproduce it.

There would be a compile time error if you follow proper signature of init
function for use with shared library.

> A question: Would it be save to define BOOST_TEST_DYN_LINK also for static
> linkage?

No.

> I hope so as I have never, really never used different code depending on
> linker options.

We have to be tollerant to guest from other continents. Our policies
selected to work the same way for every one.

> Even after renaming my main
> test_suite* init_unit_test_suite(int, char *[])
> function into
> bool init_unit_test()
> (but only for dynamic linkage?) as noticed on
> http://www.patmedia.net/~rogeeff/html/utf/user-guide/initialization.html
> I fail as usual.

You should see compilation errors now.

> Short: In the past it was so simple:
>
> #include <boost/test/unit_test.hpp>
> using boost::unit_test::test_suite;
> test_suite* init_unit_test_suite(int, char *[])
> {
>   test_suite *test = BOOST_TEST_SUITE("Master test suite");
>   test->add(BOOST_TEST_CASE(&JacobiTest1));
>   return test;
> }
>
> Now I use
>
> * Additional autoconf code to define HAVE_UNIT_TEST_LIB if the (shared?)
> library is
>  used.
>
> #ifdef HAVE_CONFIG_H
> #include <config.h> // HAVE_UNIT_TEST_LIB
> #endif
>
> #ifdef HAVE_UNIT_TEST_LIB
> #  define BOOST_TEST_DYN_LINK
> #  include <boost/test/unit_test.hpp>
> #else
> #  include <boost/test/included/unit_test.hpp>
> #endif

1. You can use static library and no need to define BOOST_TEST_DYN_LINK for
either library of included variant
2. You can use included variant always
3. You can switch to automated registration and you don't need to define nor
function main(), nor init function

> using boost::unit_test::test_suite;
>
> bool init_unit_test()
> {
>  // my old init_unit_test_suite code
> }
>
> /*
> int main(int argc, char *argv[])
> {
>  init_unit_test_suite(argc, argv);
>  return 0;
> }
> */

If you insist on combination of manual registration with shared library, it
should look like this:

int
main( int argc, char* argv[] )
{
    return ::boost::unit_test::unit_test_main( &init_unit_test, argc,
argv );
}


> the required information is wrong and incomplete and addionally

What is wrong?

> scattered across multiple pages such as
> http://www.patmedia.net/~rogeeff/html/utf/compilation.html
> http://www.patmedia.net/~rogeeff/html/utf/compilation/direct-include.html
> http://www.patmedia.net/~rogeeff/html/utf/user-guide/usage-variants.html
> (and all referenced sub pages)
> http://www.patmedia.net/~rogeeff/html/utf/user-guide/test-runners.html
> http://www.patmedia.net/~rogeeff/html/utf/user-guide/initialization.html

If you can express it all better I am open to sugestions. It is indeed not
very trivial (considering many different usage variant of Boost.Test) to
describe all necessary information and be both complete and easily
accessible to first timers.

> To show you that I really read (at least up to UTF) the documenation I
> mention
> a few errors in it:

I'll look on these later.

Thanks for the comments

Gennadiy



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Ilya Sokolov]

Sorry for breaking into discussion but I have a bunch of related questions.

Gennadiy Rozental wrote:
> "Jens Seidel" <jensseidel@...> 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?

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);
}

Now if I want to support using static Boost.Test, I am forced to define
BOOST_TEST_ALTERNATIVE_INIT_API.

>> I thought I have also seen a conflict with my own init_unit_test_suite()
>> implementation if I define BOOST_TEST_MAIN but cannot reproduce it.
>
> There would be a compile time error if you follow proper signature of init
> function for use with shared library.
>
>> A question: Would it be save to define BOOST_TEST_DYN_LINK also for static
>> linkage?
>
> No.
>
>> I hope so as I have never, really never used different code depending on
>> linker options.
>
> We have to be tollerant to guest from other continents. Our policies
> selected to work the same way for every one.
>
>> Even after renaming my main
>> test_suite* init_unit_test_suite(int, char *[])
>> function into
>> bool init_unit_test()
>> (but only for dynamic linkage?) as noticed on
>> http://www.patmedia.net/~rogeeff/html/utf/user-guide/initialization.html
>> I fail as usual.
>
> You should see compilation errors now.
>
>> Short: In the past it was so simple:
>>
>> #include <boost/test/unit_test.hpp>
>> using boost::unit_test::test_suite;
>> test_suite* init_unit_test_suite(int, char *[])
>> {
>>   test_suite *test = BOOST_TEST_SUITE("Master test suite");
>>   test->add(BOOST_TEST_CASE(&JacobiTest1));
>>   return test;
>> }
>>
>> Now I use
>>
>> * Additional autoconf code to define HAVE_UNIT_TEST_LIB if the (shared?)
>> library is
>>  used.
>>
>> #ifdef HAVE_CONFIG_H
>> #include <config.h> // HAVE_UNIT_TEST_LIB
>> #endif
>>
>> #ifdef HAVE_UNIT_TEST_LIB
>> #  define BOOST_TEST_DYN_LINK
>> #  include <boost/test/unit_test.hpp>
>> #else
>> #  include <boost/test/included/unit_test.hpp>
>> #endif
>
> 1. You can use static library and no need to define BOOST_TEST_DYN_LINK for
> either library of included variant
> 2. You can use included variant always
> 3. You can switch to automated registration and you don't need to define nor
> function main(), nor init function
>
>> using boost::unit_test::test_suite;
>>
>> bool init_unit_test()
>> {
>>  // my old init_unit_test_suite code
>> }
>>
>> /*
>> int main(int argc, char *argv[])
>> {
>>  init_unit_test_suite(argc, argv);
>>  return 0;
>> }
>> */
>
> If you insist on combination of manual registration with shared library, it
> should look like this:
>
> int
> main( int argc, char* argv[] )
> {
>     return ::boost::unit_test::unit_test_main( &init_unit_test, argc,
> argv );
> }
>
>
>> the required information is wrong and incomplete and addionally
>
> What is wrong?
>
>> scattered across multiple pages such as
>> http://www.patmedia.net/~rogeeff/html/utf/compilation.html
>> http://www.patmedia.net/~rogeeff/html/utf/compilation/direct-include.html
>> http://www.patmedia.net/~rogeeff/html/utf/user-guide/usage-variants.html
>> (and all referenced sub pages)
>> http://www.patmedia.net/~rogeeff/html/utf/user-guide/test-runners.html
>> http://www.patmedia.net/~rogeeff/html/utf/user-guide/initialization.html
>
> If you can express it all better I am open to sugestions. It is indeed not
> very trivial (considering many different usage variant of Boost.Test) to
> describe all necessary information and be both complete and easily
> accessible to first timers.
>
>> To show you that I really read (at least up to UTF) the documenation I
>> mention
>> a few errors in it:
>
> I'll look on these later.
>
> Thanks for the comments
>
> Gennadiy
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Jens Seidel]

Hi Gennadiy,

first of all thanks for your comments. Some stuff is now a little bit
more understandable other stuff not.

I hope you didn't considered my mails as complaints, I just tried to
express that some parts of Boost.Test need some improvement. To be
honest I think that your library is a very important one and well done.
I will definitively look into it more carefully (reading the code/the
docs multiple days) as it is impossible to understand the current
implemention compared to the old outdated documenation with current
resources in let's say less than one day.

Please note that I'm also willing to resolve these issues and will
try some improvements to the documenation. I have to confess that
I did not write much documenation myself but I'm (mostly as translator)
involved in many Open Source documents such as Debian Reference, Debian
Website and other documents (HOWTOs, manpages, ...). I know XML and SGML
based tools really well (and maintain these partely myself) so I do not
expect problems with Boost documentation system.

I don't have much time to explain all my issues with Boost.Test now in
detail (I still have to buy some presents :-) but I will at least
answer your questions:

On Fri, Dec 21, 2007 at 02:27:31AM -0500, Gennadiy Rozental wrote:
> "Jens Seidel" <jensseidel@...> wrote in message
> news:20071219090237.GA13691@......
> > And why are static and shared libraries handled differently? Why not
> > just removing main also from static libraries?

Let me again note that I think that the words "static" and "shared" do
not match here as both libraries are indeed different ones (which share
a lot of code). This *needs* to be fixed! The current situation is
clearly NOT acceptable (no joke!).
 
> 1. For backward compartibility

Here you assume that most users do not use the shared library. OK, let's
assume this for now.

> 2. For enhanced usebility in many cases. For people producing a lot of unit
> tests adding extra function main()
> implementation is unnnecessary burdan (not mentioning that they will have to
> actually learn how implement it properly.

Confusing users with all kind of combinations of BOOST_TEST_DYN_LINK,
BOOST_TEST_MAIN, BOOST_TEST_ALTERNATIVE_INIT_API, usage or not usage
of main and the init method is OK?

I'm sure many combination of these flags are just incompatible to each
other. Defining a one line main() method (containing also test module
initialization API code) instead of using macros would simplify a lot
in code and documentaion (but would require a new API :-().

> 3. In many (if not the most) cases function main() handling is hidden
> completely from the users and usage and both usage variants behave pretty
> much the same. The only difference is presence of an extra macro
> BOOST_TEST_DYN_LINK.

Maybe. But I was never largely involved into Boost.Test and followed the
first time mainly the normal starting instructions from the old docs
(which are very easy!) and extented some parts later as needed
(test_tools::predicate_result stuff, ...). So I consider my code the
normal use case and you think it is very exotic as nearly no part of the
documentation and your mails adress my usage?
 
> You comming to this from *nix prospecive.

Right.

> On NT dll and lib are two quite
> different ball games. Boost.Test opted to be consystent in between
> platforms.

But why not select the best of both systems? (To be honest I do not know
anything with could be used from your propritary world.)
You did it the opposite way.
 
> > 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)
>
> I sugest I write Boost.Test using C? In Boost.Test  a lot of staff happends

The first "I" should probably be "You".

> in headers. We might find it difficult.

No, one can also use ABIs in C++. Included code is part of the binary if
it comes from headers and fixed even if you move the binary to another
system where different shared libraries may be installed. ABI affects
exported symbols in shared libraries only. As most Boost libs are indeed
header based ABI does not affect these.
 
> > 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)
>
> I do not plan any changes that should break backward compartibility. 1.34.1
> did break it for very small number of use cases, which where never
> officially supported in a first place (plus I believe 1 tool was found
> unsafe and the interface was changes).

A stable API is a very good think. But if the current interface is
unusable (and also impossible to document) it may be useful.

All Boost libraries need to pass an initial review. Is it possible to
rewrite libs after it completely (as you did????) or would it make sense
to ask the community if changes are worth to be done?
 
> > 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 ...
>
> I am sure we will be able to figure it out.

Would be great!

> As far as i know there is no problem compiling/linking Boost.Test.

I did not wrote about problems compiling Boost.Test but about using it!
I prefer of course to use Boost from the packages provided on my system.
Even if Boost isn't installed by default it is possible to select it for
installation during seconds on each modern system.

> > 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??????)

This seems to be one of the most important questions: Why do you not
replace http://www.boost.org/libs/test/doc/index.html with
http://www.patmedia.net/~rogeeff/html/index.html?
Does the content need to be transfered from HTML first or what steps are
missing?

> > you should assume that most code arround does not provide
> > main() and fails that's why starting with recent versions.
>
> Only those who employ shared library and manual registration had an issue.

Which is the default case in the old documentation. I also see some
advantages:

* No usage of just another macro
* It's easier to uncomment a test (only a single line needs a comment,
  the compiler can still check the syntax of the not used test
* I know the order of the execution of the tests for sure and can test
  basic stuff at the beginning

> > How could I define my own main function which is compatible with shared
> > and dynamic libraries? unit_test_main has different signatures!?
>
> 1. shared and dynamic libs are comparitble ;)

I assume you forgot "not" here. Otherwise you refer to code rewriting
(automatic registration, ...)?

> 2. Don't define init function at all.

I need an init function. I use a logger and set some parts to verbose
file output and compare as another test the generated output with
expected one. I would nevertheless like to do this directly in main()
without need for another init function.

> 3. The test runner  function signature is now the same for both static and
> dyanmic library (see svn). I am yet to update the updated docs ;)
 
Good.

> Yes, the version on boost.org is very old. Docs writting take as much time
> (if not more) as actual development.

I fully agree. But why not using the best of both? Remove outdated
pages on www.boost.org with your new docu *now*. Why do you wait?
 
> > Again: Why are
> > static and shared libraries handled differently? It shouldn't matter!
>
> It does on windows.

But it does not have to differ! Most Open Source code from Linux can be
compiled on Windows as well. Do you think part of the porting is to
change interfaces just for fun? It is not necessary!

Jens
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Jens Seidel]

On Fri, Dec 21, 2007 at 02:51:40AM -0500, Gennadiy Rozental wrote:
> "Jens Seidel" <jensseidel@...> wrote in message
> news:20071220161635.GA515@......
> > I read most of the new documentation but to make it short: I still fail
> > to use unit tests. It worked in the past but after a lot of changes
> > in Boost.Tests it is now unusable for me.
>
> Let's  see concrete examples.

Old code was as simple as:

#include <boost/test/unit_test.hpp>
using boost::unit_test::test_suite;

test_suite* Jacobi_test_suite();

test_suite* init_unit_test_suite(int, char *[])
{
  Initialize_logging();
  test_suite *test = BOOST_TEST_SUITE("Master test suite");
  test->add(Jacobi_test_suite());
  return test;
}

> >> > prefer to define main youself and invoke init function you can do it as
> >> > well
> >> > with shared library variant.
> >
> > And how?
>
> See example 9 on
>
> http://www.patmedia.net/~rogeeff/html/utf/user-guide/test-organization/manual-nullary-test-case.html

Right. Thanks! Just changing

test_suite* init_unit_test_suite(int, char *[])
{
  Initialize_logging();
  test_suite *test = BOOST_TEST_SUITE("Master test suite");
  test->add(Jacobi_test_suite());
  return test;
}

into

bool init_unit_test()
{
  Initialize_logging();
  boost::unit_test::framework::master_test_suite().add(Jacobi_test_suite());

  return true;
}

int main(int argc, char *argv[])
{
  return ::boost::unit_test::unit_test_main(&init_unit_test, argc, argv);
}

works. Please note that one has to read dozens of pages before as this
is nearly at the end of the documentation.

Is this kind of usage really so difficult that you think it is worth the
effort to hide it for the user and suggest automatic registration
instead?
 

> > Including the header boost/test/included/unit_test.hpp *once* per binary
> > seems
> > to work but normal using of boost/test/unit_test.hpp together with an
> > additional
> > #define BOOST_TEST_DYN_LINK
> > still leads to a missing main() function. I get since 1.34.1:
> > /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crt1.o: In function
> > `_start':
> > (.text+0x18): undefined reference to `main'
> > collect2: ld returned 1 exit status
>
> You also need to define either BOOST_TEST_MODULE or BOOST_TEST_MAIN if you
> want Boost.Test to generate main function for you. Like in an example 18
> here:
>
> http://www.patmedia.net/~rogeeff/html/utf/user-guide/test-organization/master-test-suite.html

That's completely different from my current code. I will definitevly not
use it as it uses too many macros (BOOST_TEST_MODULE,
BOOST_AUTO_TEST_CASE and the probably required BOOST_TEST_DYN_LINK). It
seems also impossible for me to use template functions as tests (which I
currently use:
template<bool var> void JacobiTest2();
test->add(BOOST_TEST_CASE(&JacobiTest2<true>));
test->add(BOOST_TEST_CASE(&JacobiTest2<false>));
 
Macros are evil!

> > I also defined BOOST_TEST_DYN_LINK on the comandline to ensure that all
> > code
> > uses it. Same result! Defining addionally BOOST_TEST_MAIN results in a
> > a proper empty test with the output
> > "Test setup error: test tree is empty"
>
> Because BOOST_TEST_MAIN produces both function main and empty init function.

According to
http://www.patmedia.net/~rogeeff/html/utf/compilation.html#utf.flag.main:
BOOST_TEST_MAIN   Define this flag to generate an empty test module
                  initialization function.

I do not read anything about main().

> It's assumed that test units are automatically registered.

I don't see many advantages as it only saved a single line of code and
requires just another macro.
 

> > Short: In the past it was so simple:
> >
> > #include <boost/test/unit_test.hpp>
> > using boost::unit_test::test_suite;
> > test_suite* init_unit_test_suite(int, char *[])
> > {
> >   test_suite *test = BOOST_TEST_SUITE("Master test suite");
> >   test->add(BOOST_TEST_CASE(&JacobiTest1));
> >   return test;
> > }
> >
> > Now I use
> >
> > * Additional autoconf code to define HAVE_UNIT_TEST_LIB if the (shared?)
> > library is
> >  used.
> >
> > #ifdef HAVE_CONFIG_H
> > #include <config.h> // HAVE_UNIT_TEST_LIB
> > #endif
> >
> > #ifdef HAVE_UNIT_TEST_LIB
> > #  define BOOST_TEST_DYN_LINK
> > #  include <boost/test/unit_test.hpp>
> > #else
> > #  include <boost/test/included/unit_test.hpp>
> > #endif
>
> 1. You can use static library and no need to define BOOST_TEST_DYN_LINK for
> either library of included variant
> 2. You can use included variant always
> 3. You can switch to automated registration and you don't need to define nor
> function main(), nor init function

 
> If you insist on combination of manual registration with shared library, it
> should look like this:
>
> int
> main( int argc, char* argv[] )
> {
>     return ::boost::unit_test::unit_test_main( &init_unit_test, argc,
> argv );
> }

Without changing the registration to use
framework::master_test_suite()->add(Jacobi_test_suite())
I would still get:
Test setup error: test tree is empty
 

> > scattered across multiple pages such as
> > http://www.patmedia.net/~rogeeff/html/utf/compilation.html
> > http://www.patmedia.net/~rogeeff/html/utf/compilation/direct-include.html
> > http://www.patmedia.net/~rogeeff/html/utf/user-guide/usage-variants.html
> > (and all referenced sub pages)
> > http://www.patmedia.net/~rogeeff/html/utf/user-guide/test-runners.html
> > http://www.patmedia.net/~rogeeff/html/utf/user-guide/initialization.html
>
> If you can express it all better I am open to sugestions. It is indeed not
> very trivial (considering many different usage variant of Boost.Test) to
> describe all necessary information and be both complete and easily
> accessible to first timers.

I suggest to simple reduce many different usage variants of Boost.Test!
Let the user always specify main(), remove the init_unit_test parameter
together with most of the macros as BOOST_TEST_DYN_LINK,
BOOST_TEST_MAIN, BOOST_TEST_ALTERNATIVE_INIT_API, ...
This will result in only two or three lines more of code but will be
much easier to understand and to document (compare the clear old
documentation!).

Jens
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Dean Michael Berris]

Hi Jens,

This is in response to one of your points in this conversation:

On Dec 21, 2007 9:23 PM, Jens Seidel <jensseidel@...> wrote:
>
> On Fri, Dec 21, 2007 at 02:27:31AM -0500, Gennadiy Rozental wrote:
> > Yes, the version on boost.org is very old. Docs writting take as much time
> > (if not more) as actual development.
>
> I fully agree. But why not using the best of both? Remove outdated
> pages on www.boost.org with your new docu *now*. Why do you wait?
>

The reason is because the version in www.boost.org pertains to
documentation for the latest release of the code -- which is 1.34.1.
If you're looking at and/or using the Boost.Test version in Trunk,
then you should be able to generate the documentation from the
distribution you've downloaded.

Now, if you're saying that 1.34.1's documentation is not consistent
with the released version, then perhaps it would be more productive if
you look at how the Boost C++ Library does its development and release
process -- then submit patches slated for 1.35. It's not like we just
update a Wiki page and it pertains to the current stable version as
far as documentation goes.

> > > Again: Why are
> > > static and shared libraries handled differently? It shouldn't matter!
> >
> > It does on windows.
>
> But it does not have to differ! Most Open Source code from Linux can be
> compiled on Windows as well. Do you think part of the porting is to
> change interfaces just for fun? It is not necessary!
>

It differs because Windows treats DLL's differently from how Linux
deals with shared object files (.so's).

Boost.Test uses macro's to hide the details you otherwise have to
worry about on a per platform basis -- like how do you load DLL's, and
how do you leverage autolinking in Windows. Much of this stuff you
don't have to worry about in Linux especially if you've got Linux
specific constructs in your main(), but that makes your code
non-platform specific.

I hope this helps.

--
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
[http://cplusplus-soup.blogspot.com/]
[mikhailberis@...]
[[phone]]
[[phone]]
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gennadiy Rozental-2]

"Jens Seidel" <jensseidel@...> wrote in message
news:20071220161635.GA515@......
> To show you that I really read (at least up to UTF) the documenation I
> mention
> a few errors in it:
>
> http://www.patmedia.net/~rogeeff/html/faq.html:
> * "provide provide"

fixed

> * "link with libunit_test_framework.lib"
>    that's platform specific!!!

Why?

> * "The reasons for this error is that in your implementation you should
>    specify second argument of init_unit_test_suite exactly as in a
>    specification, i.e.: char* []."
>   s/as in a specification/as in the specification/ (I first read e.g.
>   instead of i.e. which confused me even more, maybe you should avoid
> "i.e.".)

fixed

> http://www.patmedia.net/~rogeeff/html/open-issues.html
> * "Finish update for CLA support"
>   What is CLA?

I removed abbriviation

> * Remove two or three full stops in the enumeration

What do you mean?

> * "Better Unicode support (reports and log in wostream)"
>   Sorry, I don't see any relation of wostream and Unicode!
>   You mean UTF16 encoding? UTF8 should work fine with both
>   ostream and wostream, right?

I 'll be more equipped to to answer this once I start doing this.

> http://www.patmedia.net/~rogeeff/html/execution-monitor.html
> * "Also The Execution Monitor"
>   s/The/the/

fixed

> http://www.patmedia.net/~rogeeff/html/execution-monitor/reference.html
> * Page misses a "next" link to
>   http://www.patmedia.net/~rogeeff/html/boost/execution_exception.html

This is being reworked.

> http://www.patmedia.net/~rogeeff/html/prg-exec-monitor/impl.html
> * Link to libs/test/execution_monitor.cpp does not work

should work now

> * "wraps a several system headers"
>   s/a//

fixed

> http://www.patmedia.net/~rogeeff/html/minimal.html
> * "other then include boost/test/minimal.hpp"
>   s/include/including/
> * "This approach is are similar" (belongs to folded text for example 4)
>   s/are//

fixed

> http://www.patmedia.net/~rogeeff/html/tutorials/intro-in-testing.html
> * "why testing worth the effort"
>   s/testing/testing is/

fixed

> http://www.patmedia.net/~rogeeff/html/tutorials/new-year-resolution.html
> * s/BOOST_AUTO_EST_CASE/BOOST_AUTO_TEST_CASE/
> * "As a result my test suite became to look like this:"
>   Wrong example!!! data_access_test() was expected

fixed

> http://www.patmedia.net/~rogeeff/html/utf/user-guide/initialization.html
> * "Alternatively in you can employ"
>   s/in//

fixed

> * "with the static library or single-header variants of the UTF requires
> the
>    specific function specification."
>   Check this! s/specification/signature/, s/specific/original/?

No, namely specification: both signature and function name. And it's quite
specific. I agree it doesn't sound right though.

Thanks for your comments.

Gennadiy



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gennadiy Rozental-2]

"Ilya Sokolov" <fal_delivery@...> wrote in message
news:fkg1cd$gdv$1@......

> Sorry for breaking into discussion but I have a bunch of related
> questions.
>
> Gennadiy Rozental wrote:
>> "Jens Seidel" <jensseidel@...> 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) 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.

> 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 );

> 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? 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.

Gennadiy



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gennadiy Rozental-2]

"Jens Seidel" <jensseidel@...> wrote in message
news:20071221141109.GB9314@......

> On Fri, Dec 21, 2007 at 02:51:40AM -0500, Gennadiy Rozental wrote:
>> "Jens Seidel" <jensseidel@...> wrote in message
>> news:20071220161635.GA515@......
>> > I read most of the new documentation but to make it short: I still fail
>> > to use unit tests. It worked in the past but after a lot of changes
>> > in Boost.Tests it is now unusable for me.
>>
>> Let's  see concrete examples.
>
> Old code was as simple as:
>
> #include <boost/test/unit_test.hpp>
> using boost::unit_test::test_suite;
>
> test_suite* Jacobi_test_suite();

where this function is defined? Why can't you automatically register your
test units?

> test_suite* init_unit_test_suite(int, char *[])
> {
>  Initialize_logging();

This should go into global fixture

>  test_suite *test = BOOST_TEST_SUITE("Master test suite");
>  test->add(Jacobi_test_suite());
>  return test;
> }
>
>> >> > prefer to define main youself and invoke init function you can do it
>> >> > as
>> >> > well
>> >> > with shared library variant.
>> >
>> > And how?
>>
>> See example 9 on
>>
>> http://www.patmedia.net/~rogeeff/html/utf/user-guide/test-organization/manual-nullary-test-case.html
>
> Right. Thanks! Just changing
>
> test_suite* init_unit_test_suite(int, char *[])
> {
>  Initialize_logging();
>  test_suite *test = BOOST_TEST_SUITE("Master test suite");
>  test->add(Jacobi_test_suite());
>  return test;
> }
>
> into
>
> bool init_unit_test()
> {
>  Initialize_logging();
>
> boost::unit_test::framework::master_test_suite().add(Jacobi_test_suite());
>
>  return true;
> }
>
> int main(int argc, char *argv[])
> {
>  return ::boost::unit_test::unit_test_main(&init_unit_test, argc, argv);
> }
>
> works. Please note that one has to read dozens of pages before as this
> is nearly at the end of the documentation.
>
> Is this kind of usage really so difficult that you think it is worth the
> effort to hide it for the user and suggest automatic registration
> instead?

Yes. I believe you describing an extreme case. At this point there are no
good/common reasons to implement your test module like this. The only one I
can think of if you want to manage what test unis to execute yourself within
init function for some reason. Everything else can be done more efficiently
with aut-registration facilities. Another reason is that the test module
might be written already in old style. In this case you might not want to
invest time into converting it. Boost.Test still supprots it. But it
requires small changes in case if you were using shared library.

>> > Including the header boost/test/included/unit_test.hpp *once* per
>> > binary
>> > seems
>> > to work but normal using of boost/test/unit_test.hpp together with an
>> > additional
>> > #define BOOST_TEST_DYN_LINK
>> > still leads to a missing main() function. I get since 1.34.1:
>> > /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crt1.o: In function
>> > `_start':
>> > (.text+0x18): undefined reference to `main'
>> > collect2: ld returned 1 exit status
>>
>> You also need to define either BOOST_TEST_MODULE or BOOST_TEST_MAIN if
>> you
>> want Boost.Test to generate main function for you. Like in an example 18
>> here:
>>
>> http://www.patmedia.net/~rogeeff/html/utf/user-guide/test-organization/master-test-suite.html
>
> That's completely different from my current code. I will definitevly not
> use it as it uses too many macros (BOOST_TEST_MODULE,
> BOOST_AUTO_TEST_CASE and the probably required BOOST_TEST_DYN_LINK). It

You are mixing in a lot of different concepts. Each macro serve it's purpose
and only used when required.

> seems also impossible for me to use template functions as tests (which I
> currently use:
> template<bool var> void JacobiTest2();
> test->add(BOOST_TEST_CASE(&JacobiTest2<true>));
> test->add(BOOST_TEST_CASE(&JacobiTest2<false>));

I don't see any problems doing above. But the UTF provides better way to
implement this through test case template support. It has both automated and
manual registration.

> Macros are evil!

They might be, but they might be also a quite powerfull code generation
tool. The Boost.Test is very carefull in how it's defines and names macros.
I might find it difficult to avoid them, since more than 80% of library
interfaces is based on macros.

>> > I also defined BOOST_TEST_DYN_LINK on the comandline to ensure that all
>> > code
>> > uses it. Same result! Defining addionally BOOST_TEST_MAIN results in a
>> > a proper empty test with the output
>> > "Test setup error: test tree is empty"
>>
>> Because BOOST_TEST_MAIN produces both function main and empty init
>> function.
>
> According to
> http://www.patmedia.net/~rogeeff/html/utf/compilation.html#utf.flag.main:
> BOOST_TEST_MAIN   Define this flag to generate an empty test module
>                  initialization function.
>
> I do not read anything about main().

Hmmmm. It's realy early in documentation to alk about complications like
this. I've added statement in this regard. Let me know if it's clearer now
(I'll post updated docs later today)

>> It's assumed that test units are automatically registered.
>
> I don't see many advantages as it only saved a single line of code and
> requires just another macro.

It saves much more than 1 line.

Compare:

void my_test_case()
{
   ...
}

bool init_unit_test()
{
    boost::unit_test::framework::master_test_suite().add(Jacobi_test_suite());

    return true;
}

with

BOOST_AUTO_TEST_CASE( my_test_case )
{
 ...
}

>> > Short: In the past it was so simple:
>> >
>> > #include <boost/test/unit_test.hpp>
>> > using boost::unit_test::test_suite;
>> > test_suite* init_unit_test_suite(int, char *[])
>> > {
>> >   test_suite *test = BOOST_TEST_SUITE("Master test suite");
>> >   test->add(BOOST_TEST_CASE(&JacobiTest1));
>> >   return test;
>> > }
>> >
>> > Now I use
>> >
>> > * Additional autoconf code to define HAVE_UNIT_TEST_LIB if the
>> > (shared?)
>> > library is
>> >  used.
>> >
>> > #ifdef HAVE_CONFIG_H
>> > #include <config.h> // HAVE_UNIT_TEST_LIB
>> > #endif
>> >
>> > #ifdef HAVE_UNIT_TEST_LIB
>> > #  define BOOST_TEST_DYN_LINK
>> > #  include <boost/test/unit_test.hpp>
>> > #else
>> > #  include <boost/test/included/unit_test.hpp>
>> > #endif
>>
>> 1. You can use static library and no need to define BOOST_TEST_DYN_LINK
>> for
>> either library of included variant
>> 2. You can use included variant always
>> 3. You can switch to automated registration and you don't need to define
>> nor
>> function main(), nor init function
>
>> If you insist on combination of manual registration with shared library,
>> it
>> should look like this:
>>
>> int
>> main( int argc, char* argv[] )
>> {
>>     return ::boost::unit_test::unit_test_main( &init_unit_test, argc,
>> argv );
>> }
>
> Without changing the registration to use
> framework::master_test_suite()->add(Jacobi_test_suite())
> I would still get:
> Test setup error: test tree is empty

I am not sure I am following. You do need to register your test units.

>> If you can express it all better I am open to sugestions. It is indeed
>> not
>> very trivial (considering many different usage variant of Boost.Test) to
>> describe all necessary information and be both complete and easily
>> accessible to first timers.
>
> I suggest to simple reduce many different usage variants of Boost.Test!
> Let the user always specify main(), remove the init_unit_test parameter
> together with most of the macros as BOOST_TEST_DYN_LINK,
> BOOST_TEST_MAIN, BOOST_TEST_ALTERNATIVE_INIT_API, ...
> This will result in only two or three lines more of code but will be

In most cases it's more than that. And many people are not willing to
sacrify that. There is also the notion of init function and you will still
need BOOST_TEST_MAIN. In addition the change wouldn't be backward
compartible and many people will not be happy.

Gennadiy




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gennadiy Rozental-2]

"Jens Seidel" <jensseidel@...> wrote in message
news:20071221132309.GA9314@......

> Hi Gennadiy,
>
> first of all thanks for your comments. Some stuff is now a little bit
> more understandable other stuff not.
>
> I hope you didn't considered my mails as complaints, I just tried to
> express that some parts of Boost.Test need some improvement. To be
> honest I think that your library is a very important one and well done.
> I will definitively look into it more carefully (reading the code/the
> docs multiple days) as it is impossible to understand the current
> implementation compared to the old outdated documentation with current
> resources in let's say less than one day.
>
> Please note that I'm also willing to resolve these issues and will
> try some improvements to the documentation. I have to confess that
> I did not write much documentation myself but I'm (mostly as translator)
> involved in many Open Source documents such as Debian Reference, Debian
> Website and other documents (HOWTOs, manpages, ...). I know XML and SGML
> based tools really well (and maintain these partely myself) so I do not
> expect problems with Boost documentation system.
>
> I don't have much time to explain all my issues with Boost.Test now in
> detail (I still have to buy some presents :-) but I will at least
> answer your questions:
>
> On Fri, Dec 21, 2007 at 02:27:31AM -0500, Gennadiy Rozental wrote:
>> "Jens Seidel" <jensseidel@...> wrote in message
>> news:20071219090237.GA13691@......
>> > And why are static and shared libraries handled differently? Why not
>> > just removing main also from static libraries?
>
> Let me again note that I think that the words "static" and "shared" do
> not match here as both libraries are indeed different ones (which share
> a lot of code). This *needs* to be fixed! The current situation is
> clearly NOT acceptable (no joke!).

They are not different in most part. The only part that is different is test
runner signature and required init function signature.

>> 1. For backward compatibility
>
> Here you assume that most users do not use the shared library. OK, let's
> assume this for now.

Till 1.34.1 shared library was not officially supported at all.

>> 2. For enhanced usability in many cases. For people producing a lot of
>> unit
>> tests adding extra function main()
>> implementation is unnecessary burden (not mentioning that they will have
>> to
>> actually learn how implement it properly.
>
> Confusing users with all kind of combinations of BOOST_TEST_DYN_LINK,
> BOOST_TEST_MAIN, BOOST_TEST_ALTERNATIVE_INIT_API, usage or not usage
> of main and the init method is OK?

1. IMO majority of the users will never need to know anything about
BOOST_TEST_ALTERNATIVE_INIT_API
2. What do you find confusing? BOOST_TEST_DYN_LINK and BOOST_TEST_MAIN
macros serve separate and orthogonal purposes.
3. IMO majority of the users will never need to know anything about both
init and main() functions.

> I'm sure many combination of these flags are just incompatible to each
> other.

BOOST_TEST_MAIN and BOOST_TEST_DYN_LINK are for the most part orthogonal.

> Defining a one line main() method (containing also test module
> initialization API code) instead of using macros would simplify a lot
> in code and documentation (but would require a new API :-().

 And is not necessary in majority of use case IMO. It might simplify docs
though.

>> 3. In many (if not the most) cases function main() handling is hidden
>> completely from the users and usage and both usage variants behave pretty
>> much the same. The only difference is presence of an extra macro
>> BOOST_TEST_DYN_LINK.
>
> Maybe. But I was never largely involved into Boost.Test and followed the
> first time mainly the normal starting instructions from the old docs
> (which are very easy!) and extended some parts later as needed
> (test_tools::predicate_result stuff, ...). So I consider my code the
> normal use case and you think it is very exotic as nearly no part of the
> documentation and your mails address my usage?

Your use case is still supported, unless I am missing something. It's just
is not considered the most user friendly and accordingly might require extra
leg work.

>> You coming to this from *nix prospective.
>
> Right.
>
>> On NT dll and lib are two quite
>> different ball games. Boost.Test opted to be consistent in between
>> platforms.
>
> But why not select the best of both systems? (To be honest I do not know
> anything with could be used from your proprietary world.)
> You did it the opposite way.

I did it in a way to make library portable in between different platforms.
Being consistent in between different usage variants was not my primary
priority (though would be nice to have). Usually usage variant is selected
once based on some external restriction and users don't need to jump from
one to another every few seconds.

>> > 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)
>>
>> I suggest I write Boost.Test using C? In Boost.Test  a lot of staff
>> happened
>
> The first "I" should probably be "You".
>
>> in headers. We might find it difficult.
>
> No, one can also use ABIs in C++. Included code is part of the binary if
> it comes from headers and fixed even if you move the binary to another
> system where different shared libraries may be installed. ABI affects
> exported symbols in shared libraries only. As most Boost libs are indeed
> header based ABI does not affect these.

Boost.Test is still evolving. My priority is not stable ABI, but backward
compartibility in a sense that test modules that used to work should still
work when built with new version of boost. Once dust is settled we might see
stable ABI.

>> > 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)
>>
>> I do not plan any changes that should break backward compatibility.
>> 1.34.1
>> did break it for very small number of use cases, which where never
>> officially supported in a first place (plus I believe 1 tool was found
>> unsafe and the interface was changes).
>
> A stable API is a very good think. But if the current interface is
> unusable (and also impossible to document) it may be useful.

I am not sure what interface you mean, but if you refer to test runner
interface and shared library, than yes it was unusable. But shared library
never was part of "contract".  It was never tested against and only existed
on some platforms as a fluke of make system. There were no problems with pre
1.34 interfaces for static library and they stay the same. There were new
interfaces introduced for automated test units registration, but old one
still supported.

> All Boost libraries need to pass an initial review. Is it possible to
> rewrite libs after it completely (as you did????) or would it make sense
> to ask the community if changes are worth to be done?

The public interfaces were not changed in most part, though the library did
undergo major implementation rework somewhere in between 1.33 and 1.34. In a
retrospect It might've been useful to do a mini review.

>> As far as I know there is no problem compiling/linking Boost.Test.
>
> I did not wrote about problems compiling Boost.Test but about using it!

I means problems compiling/linking of test modules with Boost.Test.

> I prefer of course to use Boost from the packages provided on my system.
> Even if Boost isn't installed by default it is possible to select it for
> installation during seconds on each modern system.

So select one usage variant (static or shared)  and stick with it. Why do
you concerned with inter-variant compatibility.

>> > 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??????)
>
> This seems to be one of the most important questions: Why do you not
> replace http://www.boost.org/libs/test/doc/index.html with
> http://www.patmedia.net/~rogeeff/html/index.html?
> Does the content need to be transferred from HTML first or what steps are
> missing?

1. I do not how to do it
2. I do not know if it possible at all.
3. The later version is beta I am still working on.

>> > you should assume that most code around does not provide
>> > main() and fails that's why starting with recent versions.
>>
>> Only those who employ shared library and manual registration had an
>> issue.
>
> Which is the default case in the old documentation. I also see some

No. shared library was *never* supported. for a long time the default and
only case was static library. Next was "included" variant. Next I finally
managed to support dynamic library in 1.34. Latest addition is an ability to
build test module as shared library and run using external test runner.
Users of static library and manual registration did not see any differences
when upgraded to 1.34.

> advantages:
>
> * No usage of just another macro

Not a big advantage. In fact it rather disadvantage in this case:
1. Point of test case definition and registration are remote. You may just
forget to register one and no one will notice.
2. It's repetitive: for each test case you need to repeat it second time for
registration. And in case if it's defined in another test file you will need
extern declaration as well.

> * It's easier to uncomment a test (only a single line needs a comment,
>  the compiler can still check the syntax of the not used test

It still pretty simple to comment out single test case. And in 1.35 there
will be an ability to filter out test units by name.

> * I know the order of the execution of the tests for sure and can test
>  basic stuff at the beginning

In fact you don't. And you shouldn't. Proper test case should be self
contained.

>> > How could I define my own main function which is compatible with shared
>> > and dynamic libraries? unit_test_main has different signatures!?
>>
>> 1. shared and dynamic libs are compatible ;)
>
> I assume you forgot "not" here. Otherwise you refer to code rewriting
> (automatic registration, ...)?

No. I did not. IMO shared == dynamic.

>> 2. Don't define init function at all.
>
> I need an init function. I use a logger and set some parts to verbose
> file output and compare as another test the generated output with
> expected one. I would nevertheless like to do this directly in main()
> without need for another init function.

You are better of with global fixture. How can you compare anything with
expected output from init function?

>> 3. The test runner  function signature is now the same for both static
>> and
>> dynamic library (see svn). I am yet to update the updated docs ;)
>
> Good.

Well almost. Init function signature is different. And it;s required as an
argument in both cases.

>> > Again: Why are
>> > static and shared libraries handled differently? It shouldn't matter!
>>
>> It does on windows.
>
> But it does not have to differ! Most Open Source code from Linux can be
> compiled on Windows as well. Do you think part of the porting is to
> change interfaces just for fun? It is not necessary!

I did not change interfaces in between Linux and Windows. Static and Dynamic
libraries interface does differ.

I am afraid that might sound like repetition, but let me retell the story
again: Original Boost.Test library was working only as static library. The
problem with dynamic libraries was:
* it can't included main()
* it can't have unresolved symbols.

Accordingly original initialization interface, that is based on externally
defined init function was not going to work for shared libraries. I had
several alternatives:

1. Forget about it. This is what we were doing before 1.34
2. Change all the interfaces plus require users to define function main().
This is what you suggest. This was problematic, since there were many users
of Boost.Test already and many of them are content with macro usage and much
prefer to avoid unnecessary work of function main() definition.
3. Make an alternative interface for use with shared libraries. and require
users to implement function main oh their test modules. This solution makes
static and shared library usages incompatible. But this is the least evil I
found in this case. In addition I've changed the meaning of some of the
macro in case of dynamic library so that function main can be generated in
some cases automatically.

Hope this will clear it out,

Gennadiy



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Ilya Sokolov]

Gennadiy Rozental wrote:

> "Ilya Sokolov" <fal_delivery@...> wrote in message
> news:fkg1cd$gdv$1@......
>> Sorry for breaking into discussion but I have a bunch of related
>> questions.
>>
>> Gennadiy Rozental wrote:
>>> "Jens Seidel" <jensseidel@...> 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.

> 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
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".

>> 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
#include <boost/test/unit_test.hpp>

bool init_unit_test()
{
   boost::filesystem::initial_path();
   return true;
}

>> 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???

> 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).

> Gennadiy

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Ilya Sokolov]

Ilya Sokolov wrote:
> Gennadiy Rozental wrote:
[snip]

> I want to seamlessly migrate from static UTF to shared.

And that is important for Boost itself, for example:

http://lists.boost.org/Archives/boost/2006/11/113037.php

--- quote ---
I think the problem here is for Boost tests itself. Now, large number of
them does not work with shared linking. So, I'm about to commit
Juergen's patch that explicitly makes all Boost test link to static
version of Boost.Test

Vladimir Prus
--- end of quote ---

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gennadiy Rozental-2]

"Ilya Sokolov" <fal_delivery@...> wrote in message
news:fko5dv$g8l$1@......

> Gennadiy Rozental wrote:
>> "Ilya Sokolov" <fal_delivery@...> wrote in message
>> news:fkg1cd$gdv$1@......
>>> Sorry for breaking into discussion but I have a bunch of related
>>> questions.
>>>
>>> Gennadiy Rozental wrote:
>>>> "Jens Seidel" <jensseidel@...> 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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gennadiy Rozental-2]

"Ilya Sokolov" <fal_delivery@...> wrote in message
news:fkoag7$squ$1@......

> Ilya Sokolov wrote:
>> Gennadiy Rozental wrote:
> [snip]
>
>> I want to seamlessly migrate from static UTF to shared.
>
> And that is important for Boost itself, for example:
>
> http://lists.boost.org/Archives/boost/2006/11/113037.php
>
> --- quote ---
> I think the problem here is for Boost tests itself. Now, large number of
> them does not work with shared linking. So, I'm about to commit
> Juergen's patch that explicitly makes all Boost test link to static
> version of Boost.Test

As far as I know Boost is using shared libraries where possible and uses
static otherwise.

Gennadiy



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vladimir Prus]

Gennadiy Rozental wrote:

>
> "Ilya Sokolov" <fal_delivery@...> wrote in message
> news:fkoag7$squ$1@......
>> Ilya Sokolov wrote:
>>> Gennadiy Rozental wrote:
>> [snip]
>>
>>> I want to seamlessly migrate from static UTF to shared.
>>
>> And that is important for Boost itself, for example:
>>
>> http://lists.boost.org/Archives/boost/2006/11/113037.php
>>
>> --- quote ---
>> I think the problem here is for Boost tests itself. Now, large number of
>> them does not work with shared linking. So, I'm about to commit
>> Juergen's patch that explicitly makes all Boost test link to static
>> version of Boost.Test
>
> As far as I know Boost is using shared libraries where possible and uses
> static otherwise.

I think the point is that right now, many test Jamfiles explicitly
specify static linking to Boost.Thread. This increases disk space
requirements for running full boost testsuite, and might increase
running time, since linking static library can be slower.

Ideally, shared version of Boost.Test should be used, but given that
shared and static version has slightly different interface, this
actually requires code changes.

- Volodya


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost