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

From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2007-05-15 10:38:39

On Tue, 15 May 2007 07:33:39 -0600
Douglas Gregor <doug.gregor_at_[hidden]> wrote:

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

We were able to "work around" this problem by moving the dynamic library
out of the way, so the linker only picked up the static library.  It
worked with just the -L/-l nomenclature, and did not require a specific
listing of the static library.

This brings up an issue that impacts the build environment.  This is a
"different" approach from the norm, but hear me out...

The boost libraries already have lots of decorations.  Why not add an
extra decoration, like '-z' to static libraries so that users can easily
decide if they want the dynamic library or the static library.  My
current project naming does that, and it is very easy for an application
to specify some static and some dynamic libs with having to fuss with
-static and -dynamic, which you may not be able to control in "deep"
build systems (where the link line is automatically built for you based
on what you request.

To keep the "default" *nix behavior, we decorate the staatic library,
and do not decorate the dynamic one...

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

I agree.  Worse, our tests that now pass on 1.33 fail to build on 1.34. 
They require extra stuff in the code to work on 1.34... not the worst
thing in the world, but... here's the kicker...  we have to change every
single test program we have to accomodate these changes...

We now need to define BOOST_TEST_DYN_LINK in the appropriate build files

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.

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.

Yes, a semi-smart shell script can probably make most of these changes. 
However, it's a bit annoying to change our tests for every boost
release.

I've been a staunch supporter of Boost.Test in the past.  Right now, I'm
getting it with both barrels from fellow employees who are having to
change everything to support 1.34.  Just yesterday, one of them argued
that we have had to make major changes to our tests with every single
boost release since 1.29.

He argued that we should stop using it and use a different test
framework.  I argued that I like Boost.Test, it works for us, and the
tests are easy to write.  He said he would rather spend more time with a
more cumbersome tool than have to fix tests everytime we want to use a
new version of Boost.  He also said that the drastic changes are not
documented very well, and he has suffered enough.  I am finding it more
difficult to argue my side...