Boost logo

Boost :

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-05-16 11:14:26

"Jody Hagins" <jody-boost-011304_at_[hidden]> wrote in message
> On Wed, 16 May 2007 02:41:08 -0400
> "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> wrote:
>> > We now need to define BOOST_TEST_DYN_LINK in the appropriate build
>> > files
>> Only if you use dynamic version of the UTF. But this is common
>> requirements of all boost libraries.
> Odd, then, that we've been using many parts of boost for years, and this
> is the first time we've encountered this "common requirement." We are
> not doing anything special in this case, and the sad part is that our
> existing tests break.

BOOST_ALL_DYN_LINK or BOOST_<lib>_DYN_LINK are required for dynamic library
compilation of any library.
It worked on *nix machines before cause it happends thhat there is no
difference in usage semantic for both variants.

> Again, I reiterate, it is NOT a good thing that we have to rewrite our
> tests just to see if our code works with the latest release of boost.

I don't believe you have to.

>> > We now have to define BOOST_TEST_MAIN in all our test programs that
>> > used to get main() by simply linking to the shared library. That's
>> > a LOT of source files to change.
>> That's not true. Or rather mostly not true. If you used to use static
>> library and continue using it no change required. If you used shared
>> library
> Our tests link against the shared library, since that's what you get by
> default on *nix systems. The change breaks all existing tests.

Boost.Test by default is configured to be used with static library variant.
To use dynamic library variant you need to define above flag.

>> variants and had BOOST_TEST_AUTO_MAIN no change required either. If
>> you used
> Not true. According to the old documentation, we used
> BOOST_TEST_AUTO_MAIN only in the cases where we were using AUTO_TEST,
> which we had to change to BOOST_TEST_CASE (or some similar incantation


> -- deprecated previously, and removed now -- no real argument there
> except the lack of documentation with the release).

I did not get from above. Why do you say "Not True"? Do you mean that your
test modules linked with dynamic library variant and BOOST_AUTO_TEST_CASE
fails. It shouldn't. Did you define BOOST_TEST_DYN_LINK somewhere in your
make file?

> However, all our
> tests that use the framework instead of auto-tests have to change.

Yes. Or you could switch to static library variant and make no changes.

>> dynamic library and did not define above flag you have much bigger
>> problem. you test module won't compile at all. The initialization
>> function signature is changed.
> Hmmm. I have not experienced the problem you specify. We used
> BOOST_TEST_AUTO_MAIN for the tests that used the auto-test features, and
> did not use it for tests that were not auto-tests... for those, we
> simply defined our own test_main or whatever it is called.

That's because you did not define BOOST_TEST_DYN_LINK.

>> > In summary, I have to change EVERY SINGLE test program in my company
>> > that uses Boost.Test and does not use auto-test (though I probably
>> > need to change those as well, because that feature is deprecated...
>> > though still supported)... and EVERY SINGLE makefile that builds
>> > them.
>> What do you mean? Automatic registration facilities are not only still
>> supported in a scope thay were defined in 1.33.1, but in fact
>> significantly improved and extended. I personally recommend moving
>> all your test modules to this facilties. As for the test modules that
>> employ manual registraition and static library variant, my
>> understanding is that they worked my chance.
> I do not understand the above paragaph.

My point is that "the feature is depricated" statement is not correct.
Auto-registration facilities are live and well. Even better than before.

>> You "thought" you are linking with static library, while in fact you
>> linked
> No, I've been developing on *nix systems for over 25 years. I actually
> built the ELF support for an SVr4 variant years ago. I *knew* I was
> linking with the dynamic library. That's what I expected, and it is
> what I got. I have a bunch of tests, and linking them all with the
> static library uses a lot of extra disk space. I DO NOT want to link
> with the static library.
> For me, there are only two reasons I want to link with a static library,
> and neither of them revolves around the notion that a function lives in
> the static lib but not the dynamic lib.

In a short term you may opt to use static library variant for the test
modules that are using manual registration. If you do insist on using
dynamic library the change is an order. Here is an example from my

#include <boost/test/unit_test.hpp>
#include <boost/bind.hpp>
using namespace boost::unit_test;
void free_test_function( int i, int j )
    BOOST_CHECK( true /* test assertion */ );

init_function() {
        add( BOOST_TEST_CASE( boost::bind( &free_test_function, 1, 1 ) ) );
        add( BOOST_TEST_CASE( boost::bind( &free_test_function, 1, 2 ) ) );
        add( BOOST_TEST_CASE( boost::bind( &free_test_function, 2, 1 ) ) );

     return true;

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

>> with shared one. The only change is required for test modules that
>> employ manual registration and dynamic library variant. 1.34.0 allows
>> you now to build these on NT without any code change. But you are
>> required to make it conformant with new initalization function
>> specification and implement function main() manually. I am showing
>> example of how it's done on my Friday session.
> Again, I must be missing something. Most of our tests conform to one of
> two models. Auto-tests, which look like this (prior to necessary code
> changes to conform with 1.34)...
> #include <boost/test/auto_unit_test.hpp>
> // A number of tests, similar to this
> BOOST_AUTO_UNIT_TEST(default_normalize_test)
> {
> // ...
> }
> For these tests, we had to change BOOST_AUTO_UNIT_TEST to
> BOOST_TEST_CASE, and then we got linker errors. We then had to add
> -DBOOST_TEST_DYN_LINK to the makefiles.

And it starter to work, yes?

> Our other variant (which is much more popular) is this pattern...
> #include "boost/test/unit_test.hpp"
> // A bunch of test code
> test_suite *
> init_unit_test_suite(int, char * [])
> {
> test_suite * ts = BOOST_TEST_SUITE("simple_format_ut");
> // A number of test_suite method calls
> return ts;
> }
> For all of these tests, we had to add #define BOOST_TEST_MAIN to each

This is plain wrong. BOOST_TEST_MAIN has nothing to do with test modules
that employ manual registration.

> file (well, we could not add it to all files, we had to pick one that
> would be the "main" and add it there because we link several files into
> one test executable). We also had to add the -DBOOST_TEST_DYN_LINK flag
> in the compiler line.

And you should see an error indicating that there is no function main()

> Personally, I think this is a terrible solution. I am not a windows
> person, so I'm not sure what other options exist. I understand putting
> link-time stuff into a compile of object files that are going into a
> shared library. However, it makes no sense for executables. I like
> running my final tests of my own code with both dynamic and shared
> libraries. This way, I know I didn't build one wrongly. Using
> Boost.Test, however, I now have to compile different variants depending
> on whether I want to link with a static library or a shared library. To
> me, that is wrong and unacceptable... aside from the fact that it
> breaks my existing tests.

Do you know any other way to make dynamic library work portably?

> Let me restate that... I have come to accept the fact that our tests
> are going to change with almost every release of boost. My colleagues
> have not accepted it... mostly because they have to do most of the work,
> and I don't. However, the whole concept of compiling code based on
> linking with a static or dynamic library is just plain wrong.

I dont expect any breaking changes any more. The reason this was changes is
because dynamiclibrary support was broken and half baked.

> If you are trying for consistency, then I'd be more in favor of removing
> main() completely from the libraries than requiring different
> compilation flags depending on how it would be linked.

I considerred this option. But this would require users of static library
and manual registraition (and they are majority for now from what I
understand) to implement function main() explicetly similar to an example
above. I did make an effort to minimize an impact. If you use automated
registration (which you should try to anyway, there very small number of
cases where you cant) the new dynamic library support works without any


Boost list run by bdawes at, gregod at, cpdaniel at, john at