Re: [boost] [Test] boost_unit_test_framework and main()

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-05-16 02:16:29

"Douglas Gregor" <doug.gregor_at_[hidden]> wrote in message 
news:9F43FA00-A732-4471-B7EA-794F928E690E_at_osl.iu.edu...
On May 15, 2007, at 3:33 AM, Jürgen Hunold wrote:
> > Just #define BOOST_TEST_DYN_LINK
>
> For the shared library tests.
>
> For the static library tests, I don't define BOOST_TEST_DYN_LINK, and
> I put the .a file directly on the link line instead of using -L and -l.
>
> >
> > Taking a look at libs/test/build/Jamfile.v2 reveals
> >     : usage-requirements
> >                    <define>BOOST_TEST_NO_AUTO_LINK=1
> >                    <link>shared:<define>BOOST_TEST_DYN_LINK=1
> >
> > which Boost.Build applies automagically ;-))
>
> Users of Boost.Build are isolated from this change are isolated from
> the effects of this change due to usage-requirements. usage-
> requirements are very cool, but they hide the fact that this change
> causes real trouble for people not using Boost.Build. The very simple
> line

Note that unit tests that are using static library variant somehow works. 
That means that Boost.Build managed to link with proper lib.

> g++ mytest.cpp -I $BOOST_HDRDIR -L $BOOST_ROOT/lib -
> lboost_unit_test_framework-gcc33-mt-d
>
> fails to link. That's bad for at least two reasons: (1) it's the
> first line that someone is likely to write when trying out the unit
> test framework, and it's not going to work; (2) it's the line that
> most non-BBv2 build systems would produce, because using -L and -l
> are the common ways to link against a static library in the Unix
> world. Not the *only* way, but the common way.

I believe your expectations are not exactly correct in this case. If you are 
working with portable library, you cant expect both static and shared 
libraries works the same way, since there are major diffrences on NT 
platform. as for the way to fix above line I see several options:

1. add -static before -l
2. explicetly refer to the static lib.
3. Make Boost.Build produce different names for static/dynamic libs. 
Alternatively you can name them differently in your make system by yourself.

> There also doesn't
> seem to be any documentation that tells users that this change was
> made, or how to link to the Boost unit test framework on a *nix system.

This was in length discussed. The change occured more than your ago. That 
said I admit lack of proper docs. The tutorial session on Fraday is the 
first step to address this. The users docs should be ready some time soon.

> We've already had some user confusion on this change, e.g.,
>
> http://lists.boost.org/boost-users/2007/05/27716.php

The users of dynamic library variant in most cases only required to define 
BOOST_TEST_DYN_LINK (which is usual requirement for all boost libs). The 
Boost.Build users shouldn't have problems either. In my make system I can 
explicetly specify whether or not I want shared library to be linked with. 
In other cases one of the above should work.

> where I stole the link line above. As I was typing this note, I see
> another note requesting assistance on getting this library to link.
> Not a good sign.
>
> I think we should revert this change for 1.34.1, so that main()
> appears in both the static and the shared library. This makes the
> simple use cases (which used to work!) work again.

The difference between dynamic and static library variants are beyond 
presence of function main(). The initialization function and built in test 
runner signatures are is different. External test runners supprt 
requirements etc. Note also that it doesn't really fix problem in your 
case - it hides it. You never intended to link with shared library. And it 
worked only by chance. From general prospective there is no other way to 
make the library work portably. What I do want to see in 1.34.1 is the docs 
update.

I plan to talk about different usage variants on friday. Also we may 
discusse this during the break if you up to it.

Gennadiy