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

[Ilya Sokolov]

Gennadiy Rozental wrote:

[snip]

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

What post?

[snip]

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

Even on platforms that does not have shared libraries at all? ;-)

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

I'm trying to argue that such use case is needlessly complex.

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

[Gennadiy Rozental-2]

"Ilya Sokolov" <fal_delivery@...> wrote in message
news:fkqcr5$9g0$1@......

> Gennadiy Rozental wrote:
>
> [snip]
>
>>>> 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.
>
> What post?

Look at the bottom of
http://permalink.gmane.org/gmane.comp.lib.boost.devel/169545

> [snip]
>
>>> 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.
>
> Even on platforms that does not have shared libraries at all? ;-)

On these platform it works as well, since if there is no shared libraries no
problem can be either.

>> 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.
>
> I'm trying to argue that such use case is needlessly complex.

If you can suggest a different/easier one I'll be happy to hear it.

Gennadiy



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

[smr99]

On Sun, Dec 23, 2007 at 07:41:48PM -0500, Gennadiy Rozental wrote:

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

OK.  So reading this, I have the following question.  Suppose I'm
writing a nifty library and distributing the source code.  I write
unit tests using Boost.Test.

Now I distribute my code -- together with the tests.  Someone else
builds my code on their system and runs the tests.  I have no
control over their install of Boost: they might have static libs,
shared libs, or both.  Can I write my unit tests so that they
link and run in all three cases?

Thanks,
-Steve


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

[David Abrahams]

on Fri Dec 21 2007, Jens Seidel <jensseidel-AT-users.sf.net> wrote:

> All Boost libraries need to pass an initial review. Is it possible to
> rewrite libs after it completely (as you did????)

Yes.

> or would it make sense to ask the community if changes are worth to
> be done?

We give library maintainers total freedom to modify a library once it
is accepted; that's a very strong incentive to participate.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

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

[David Abrahams]

on Sun Dec 23 2007, "Gennadiy Rozental" <rogeeff-AT-gmail.com> wrote:

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

Oh, come on, man.  That's just too hard to swallow.
http://lists.boost.org/Archives/boost/2005/08/91786.php

> 3. The later version is beta I am still working on.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

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

[Gennadiy Rozental-2]

Steve M. Robbins <steve <at> sumost.ca> writes:
> OK.  So reading this, I have the following question.  Suppose I'm
> writing a nifty library and distributing the source code.  I write
> unit tests using Boost.Test.
>
> Now I distribute my code -- together with the tests.  Someone else
> builds my code on their system and runs the tests.  I have no
> control over their install of Boost: they might have static libs,
> shared libs, or both.  Can I write my unit tests so that they
> link and run in all three cases?

choice 1: Write your unit tests using automated registration tools:

#define BOOST_TEST_MODULE my tests
#include <boost/test/unit_test.hpp>

BOOST_AUTO_TEST_CASE( free_test_function )
{
    BOOST_CHECK( true /* test assertion */ );
}

Userls of your library will be able to test it using static library or shared
library. Later require BOOST_TEST_DYN_LINK to be added to the compilation line.

choice 2: Use single-header variant of UTF

#define BOOST_TEST_MODULE my tests
#include <boost/test/included/unit_test.hpp>

BOOST_AUTO_TEST_CASE( free_test_function )
{
    BOOST_CHECK( true /* test assertion */ );
}

You don't care about library at all.

Gennadiy

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

[Gennadiy Rozental-2]

David Abrahams <dave <at> boost-consulting.com> writes:

>
>
> on Sun Dec 23 2007, "Gennadiy Rozental" <rogeeff-AT-gmail.com> wrote:
>
> >> 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.
>
> Oh, come on, man.  That's just too hard to swallow.
> http://lists.boost.org/Archives/boost/2005/08/91786.php

Yeah. Since I never got to do it, I forgot about it. At this point I will wait
for 1.35

Gennadiy

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

[Ilya Sokolov]

Gennadiy Rozental wrote:
>>>>> 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.
>> What post?
>
> Look at the bottom of
> http://permalink.gmane.org/gmane.comp.lib.boost.devel/169545

I still don't see why is it unacceptable. Can you state it explicitly?

>>>> 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.
>> Even on platforms that does not have shared libraries at all? ;-)
>
> On these platform it works as well, since if there is no shared libraries no
> problem can be either.

Problem arise with library that should work on both platforms, with and
without dll support.

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

[Gennadiy Rozental-2]

Ilya Sokolov <fal_delivery <at> mail.ru> writes:

>
> Gennadiy Rozental wrote:
> >>>>> 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.
> >> What post?
> >
> > Look at the bottom of
> > http://permalink.gmane.org/gmane.comp.lib.boost.devel/169545
>
> I still don't see why is it unacceptable. Can you state it explicitly?

Hmm. How to state it more explicitly. How about this:

It does not link.
 
> Problem arise with library that should work on both platforms, with and
> without dll support.

What platforms are you talking about?
Why the solutions I provided are not satisfactory?

Gennadiy


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

[Ilya Sokolov]

Gennadiy Rozental wrote:
 >>>>>>> 2. Unfortunately original test modult function signature is
unacceptable for DLL initialization. So i had to introduce new one.
[snip]
 >> I still don't see why is it unacceptable. Can you state it explicitly?
 >
 > Hmm. How to state it more explicitly. How about this:
 >
 > It does not link.

i.e.,
boost::unit_test::test_suite* init_unit_test_suite( int, char* [] )
link, but
bool init_unit_test()
doesn't link?

 >> Problem arise with library that should work on both platforms, with
and without dll support.
 >
 > What platforms are you talking about?

dos/djgpp

 > Why the solutions I provided are not satisfactory?

they are too complex for such simple problem

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

[Pierre-Jules Tremblay-2]

(sorry - this should have gone thru 5 days ago)

On Dec 20, 2007 11:16 AM, Jens Seidel <jensseidel@...> wrote:

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


Well here's a success story, if it can encourage you to persevere.  We have
a library of many hundreds of manually-registered test cases grouped into
many dozen manually-registered test suites, all running under Boost.Test
1.33.1.  I'm happy to report that we had all those test cases running under
Boost.Test 1.34.1 within one hour of upgrading.  Even better: most of our
tests written since 1.34.1 came out use the automatic registration facility
and the two types of tests coexist happily (all statically linked BTW - I've
never tried the dynamic linking feature).  Even better: I've got things set
up so they are backward compatible with 1.33.1 (well, at least the
manually-registered test cases are for sure).

Like you, we define our own init_unit_test_suite() function to perform some
boilerplate initialisation.  Here's how I solved the problem.

#if (BOOST_VERSION / 100 < 1034) // Not necessary for Boost 1.34 and later.
#define init_unit_test_suite init_auto_unit_test_suite
#define BOOST_AUTO_TEST_MAIN "Automatic"
#include <boost/test/auto_unit_test.hpp>
#undef init_unit_test_suite
#endif

boost::unit_test::test_suite* init_unit_test_suite( int argc, char * argv[]
)
{
        // Create the master test suite.
#if (BOOST_VERSION / 100 < 1034) // Not necessary for Boost 1.34 and later.
        boost::unit_test::test_suite * main_suite = A2M_NEW
boost::unit_test::test_suite;
        // Add automatically-registered tests
        main_suite->add(init_auto_unit_test_suite(argc,argv));
        // Add user-defined test suites, if any
        boost::unit_test::test_suite * user_suite  =
unittest::init_unit_test_suite(argc,argv);
        if (user_suite)
        {
            main_suite->add(user_suite);
        }
#else
        boost::unit_test::test_suite * main_suite  =
unittest::init_unit_test_suite(argc,argv);
#endif

        // Initialise our own pre-test setup fixture.
        unittest::SetupFixture::Init();

        // All done.  Boost.Test framework takes over from here.
        return main_suite;
    }
}

Our test executables only need to define unittest::init_unit_test_suite() to
register manual test cases/suites if necessary (where unittest is a
namespace we chose arbitrarily).  If the test executable has no manual tests
to register, you can skip the above code and define BOOST_TEST_MODULE and
just use the auto registration and that's it.

BTW I disagree that Boost.Test should force users to define a main().  I
believe Gennadiy has made the correct compromise, which is to make the
frequent case fast (and easy), while allowing special cases to be worked in.

One suggestion might be to add a new class of fixture.  There is a feature
for test case specific fixtures, another for test suite-specifc fixtures,
and the perhaps ill-named global fixture, which is run independently for all
test cases.  Perhaps there should be another fixture, a really global one,
which is constructed before all tests are run and destroyed after all tests
are run.  A static variable won't cut it because of the
order-of-initialisation fiasco.

pj



On Dec 21, 2007 9:11 AM, Jens Seidel <jensseidel@...> wrote:

> 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<http://www.patmedia.net/%7Erogeeff/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<http://www.patmedia.net/%7Erogeeff/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<http://www.patmedia.net/%7Erogeeff/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/%7Erogeeff/html/utf/compilation.html>
> > >
> http://www.patmedia.net/~rogeeff/html/utf/compilation/direct-include.html<http://www.patmedia.net/%7Erogeeff/html/utf/compilation/direct-include.html>
> > >
> http://www.patmedia.net/~rogeeff/html/utf/user-guide/usage-variants.html<http://www.patmedia.net/%7Erogeeff/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/%7Erogeeff/html/utf/user-guide/test-runners.html>
> > >
> http://www.patmedia.net/~rogeeff/html/utf/user-guide/initialization.html<http://www.patmedia.net/%7Erogeeff/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
>

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

[Gennadiy Rozental-2]

"Ilya Sokolov" <fal_delivery@...> wrote in message
news:fkuive$ijf$1@......

> Gennadiy Rozental wrote:
> >>>>>>> 2. Unfortunately original test modult function signature is
> unacceptable for DLL initialization. So i had to introduce new one.
> [snip]
> >> I still don't see why is it unacceptable. Can you state it explicitly?
> >
> > Hmm. How to state it more explicitly. How about this:
> >
> > It does not link.
>
> i.e.,
> boost::unit_test::test_suite* init_unit_test_suite( int, char* [] )
> link, but
> bool init_unit_test()
> doesn't link?

Quite the opposite. Original testrunner/initialization function signatures
cause Boost.Test fail to build as DLL.

> >> Problem arise with library that should work on both platforms, with
> and without dll support.
> >
> > What platforms are you talking about?
>
> dos/djgpp

I am not sure Boost.Test and/or Boost support these. What compiler r u
using? Do we run regression tests on these?

> > Why the solutions I provided are not satisfactory?
>
> they are too complex for such simple problem

The problem is far from being simple and what is complicated in solution I
recomended?

Gennadiy



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

[Gennadiy Rozental-2]

"Pierre-Jules Tremblay" <boost@...> wrote in message
> One suggestion might be to add a new class of fixture.  There is a feature
> for test case specific fixtures, another for test suite-specifc fixtures,
> and the perhaps ill-named global fixture, which is run independently for
> all
> test cases.  Perhaps there should be another fixture, a really global one,
> which is constructed before all tests are run and destroyed after all
> tests
> are run.  A static variable won't cut it because of the
> order-of-initialisation fiasco.

I might be missing something, but from my understanding that is what
BOOST_GLOBAL_FIXTURE is doing. It is setup leg executed before testing is
started. Teardown once all tests are completed.

Gennadiy



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

[Benoit Sigoure]

On Dec 18, 2007, at 11:16 AM, Benoit Sigoure wrote:

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

Hi guys,
so I'm about to fix my BOOST_TEST macro that tests whether  
Boost.Tests can be used and linked against.  Hubert Figuiere  
contributed the following fix.  He suggested that I add:
   using boost::unit_test::test_suite;
   test_suite* init_unit_test_suite(int argc, char ** argv)
   {
     return NULL;
   }
Before my `main' (which reads: int main() { BOOST_CHECK(2 == 2);  
return 0; })

He said that this fixed the macro for Boost 1.33.1.  Can anyone  
confirm the fix?  I tested it on a Debian with 1.33.1 and it worked.  
I didn't find any clear conclusion in this thread and I must admit  
that I find this fix utterly awkward, so I'd be grateful if someone  
could explain it to me.

In case anyone wants to test the patch, I attached it.  If you have Git:
   git clone git://repo.or.cz/boost.m4.git  # You can use http:// if  
you're stuck behind a nazi firewall
   cd boost.m4
   git am 0001-Fix-the-test-for-Boost.Test.patch

If you don't have Git:
   wget 'http://repo.or.cz/w/boost.m4.git?
a=snapshot;h=59d8d8fd;sf=tgz' -O boost.m4.tgz
   tar xfz boost.m4.tgz
   cd boost.m4
   patch -p1 < 0001-Fix-the-test-for-Boost.Test.patch

Then in both cases, run:
   ./bootstrap
   ./configure -C
   make check TESTSUITEFLAGS='20 21'

If you have Boost < 1.34 installed (which would be great to test with  
an older version of Boost such as 1.33.1), you need to change line 29  
of configure.ac to this:
   BOOST_REQUIRE()
to drop the minimum version requirement.  Otherwise configure will  
fail (because it will try to find Boost >= 1.34).  Don't forget to re-
run ./bootstrap if you change configure.ac.

Cheers,

--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory



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

[Gennadiy Rozental-2]

Benoit Sigoure <tsuna <at> lrde.epita.fr> writes:

>
> On Dec 18, 2007, at 11:16 AM, Benoit Sigoure wrote:
> Hi guys,
> so I'm about to fix my BOOST_TEST macro that tests whether  
> Boost.Tests can be used and linked against.  Hubert Figuiere  
> contributed the following fix.  He suggested that I add:
>    using boost::unit_test::test_suite;
>    test_suite* init_unit_test_suite(int argc, char ** argv)
>    {
>      return NULL;
>    }
> Before my `main' (which reads: int main() { BOOST_CHECK(2 == 2);  
> return 0; })

I can't say I understand 100% what you are trying to do here, but using
Testing tools outside of the UnitTest framework might not be a good idea. In
1.35 I've implemented a check against it and it may throw an exception.

Gennadiy

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

[Jens Seidel]

Hi Gennadiy,

On Mon, Jan 07, 2008 at 04:26:46PM +0000, Gennadiy Rozental wrote:

> > On Dec 18, 2007, at 11:16 AM, Benoit Sigoure wrote:
> > so I'm about to fix my BOOST_TEST macro that tests whether  
> > Boost.Tests can be used and linked against.  Hubert Figuiere  
> > contributed the following fix.  He suggested that I add:
> >    using boost::unit_test::test_suite;
> >    test_suite* init_unit_test_suite(int argc, char ** argv)
> >    {
> >      return NULL;
> >    }
> > Before my `main' (which reads: int main() { BOOST_CHECK(2 == 2);  
> > return 0; })
>
> I can't say I understand 100% what you are trying to do here, but using

let me reply instead of Benoit.

The aim of the code above is to be used in boost.m4 (M4 is the GNU
macro package) to be used itself in configure scripts which are started
on each system before the compilation starts to test the system, look
for the compiler and available libraries ... Using this information a
system specific Makefile is written and the build system is portable.

So Benoit tries to find an easy way to test a system whether Boost.Test
is available. Considering the many different system configurations (think
about the CRT mess on Windows!!!) such system tests for projects using
autotools are a very important step. It is in general not possible to
hardcode paths, compiler options, ... as it will break on some exotic
systems.

With autotools compiling code is as simple as:
./configure [optional options such as --prefix=/usr/local or
             --with-boost=path ...]
make
make install

This works everywhere (yes, even on the proprietary system you're using).

Gennadiy, I don't understand the following:

> Testing tools outside of the UnitTest framework might not be a good idea. In
> 1.35 I've implemented a check against it and it may throw an exception.

What does "outside of UnitTest framework" mean? Do you refer to a
special namespace, the requirement to link against the boost-unittest
library or what?

Benoit: As Gennadiy pointed out (thanks) it is possible to define the macro
whether shared or static libraries are used directly in the Makefile.
I'm sorry to note that I consider it now your job to determine whether
you link against the shared or static library and to set BOOST_CXXFLAGS
accordingly. You probably have to check whether test code compiled with
or without a user specified main function to determine this. Maybe Gennadiy
can help even more by providing a single (two or three lines only) check
for both?

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

[Gennadiy Rozental-2]

Jens Seidel <jensseidel <at> users.sf.net> writes:
> So Benoit tries to find an easy way to test a system whether Boost.Test
> is available.

This is quite open ended question. What specifically are you trying to detect?

Presence of Boost.Test headers?
Presence of prebuild Boost.Test libraries (static and/or dynamic)?
Presence od single header variant of Boost.Test?
Presence of Unit test framework or program execution monitor or just an
execution monitor.
Support for specific feature in Boost.Test

I would guess each require separate and different test.

> What does "outside of UnitTest framework" mean? Do you refer to a
> special namespace, the requirement to link against the boost-unittest
> library or what?

No. I mean outside of test case - directly in main()
 
> Benoit: As Gennadiy pointed out (thanks) it is possible to define the macro
> whether shared or static libraries are used directly in the Makefile.
> I'm sorry to note that I consider it now your job to determine whether
> you link against the shared or static library and to set BOOST_CXXFLAGS
> accordingly.

Depending what are you are trying to find you will need different tests and
potencially different make rules.

> You probably have to check whether test code compiled with
> or without a user specified main function to determine this. Maybe Gennadiy
> can help even more by providing a single (two or three lines only) check
> for both?

I am not quite sure what main() has to do with it. From where I stand, you
don't need main() in either case.

Gennadiy

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

[Benoit Sigoure]

Hi guys,
let me just make this clear before we start: Hubert's fix (adding a  
`init_unit_test_suite' that returns NULL) works.  That is, it enable  
me to link against Boost.Test < 1.34.

On Jan 11, 2008, at 8:00 AM, Gennadiy Rozental wrote:

> Jens Seidel <jensseidel <at> users.sf.net> writes:
>> So Benoit tries to find an easy way to test a system whether  
>> Boost.Test
>> is available.
>
> This is quite open ended question. What specifically are you trying  
> to detect?
>
> Presence of Boost.Test headers?
> Presence of prebuild Boost.Test libraries (static and/or dynamic)?
> Presence od single header variant of Boost.Test?
> Presence of Unit test framework or program execution monitor or  
> just an
> execution monitor.
> Support for specific feature in Boost.Test

I want the smallest code that compiles and links against the greatest  
number of versions of Boost.Test.  This test case should use the most  
common headers of this library and must use symbols from the library  
so that the resulting object file cannot be linked without having the  
correct -lflag.  I want this test to work with as many flavors/
combinations/versions of Boost.Test as possible.

Would it be possible for you to give me the smallest dumb code that  
exercises the most basic feature of Boost.Test + compilation and  
linkage against Boost.Test?

Cheers,

--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory


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

[egoots]

Gennadiy Rozental wrote:

>>
>>>> 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.
>> Oh, come on, man.  That's just too hard to swallow.
>> http://lists.boost.org/Archives/boost/2005/08/91786.php
>
> Yeah. Since I never got to do it, I forgot about it. At this point I will wait
> for 1.35
>

It appears to me that the new docs are not yet in the 1.35 release
branch. Should they be?

http://svn.boost.org/svn/boost/branches/release/libs/test/doc/


... or am I looking in the wrong spot?

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

[Gennadiy Rozental-2]

Benoit Sigoure <tsuna <at> lrde.epita.fr> writes:
> Would it be possible for you to give me the smallest dumb code that  
> exercises the most basic feature of Boost.Test + compilation and  
> linkage against Boost.Test?

Test for single header variant; no need to link with the library:

#define BOOST_TEST_MODULE boost.m4
#include <boost/test/included/unit_test.hpp>

BOOST_AUTO_TEST_CASE( case )
{
   BOOST_ERROR( "expected" );
}

---------------------

Standalone library variants:

#define BOOST_TEST_MODULE boost.m4
#include <boost/test/unit_test.hpp>

BOOST_AUTO_TEST_CASE( case )
{
   BOOST_ERROR( "expected" );
}

This should work both for static and shared library variants. In later case
you need to add BOOST_TEST_DYN_LINK to the compiler options and corresponding
link options to enforce linking with shared library.

Some specific features of Boost.Test (like floating point comparisons) require
additional headers. We can come up with corresponding tests as well.

Gennadiy

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