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

From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2007-05-16 13:03:59

On Wed, 16 May 2007 11:14:26 -0400
"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> wrote:

> 
> "Jody Hagins" <jody-boost-011304_at_[hidden]> wrote in message 
> news:20070516092500.59f0ebd0.jody-boost-011304_at_atdesk.com...
> > 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.

Maybe I'm missing something... I am not compiling a library... I am
compiling an application that simply uses a library.  Why do I have to
specify in the compiler flags, how that object file will be linked, when
that decision is made at link time.  I have *never* used a library where
my application code had to be compiled differently depending on whether
I planned to link against a static or dynamic version of the same
library.  That just does not make any sense to me.

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

Well, your belief and my reality do not coincide ;-)  I have already
given you examples of existing tests that compiled, linked, and ran fine
with 1.33.1.  Simply changing to 1.34 results in tests that do not
build.  We had to make a number of changes (again, previously listed) to
get them working.

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

Why does there have to be a difference?  Aren't the 1.34 changes
supposed to creare more harmony?  Instead, they have now caused *nix
users to jump through crazy hoops that they never had to do before. 
That's the main thing that bothers me.

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

Because your statement was not true, at least according to my
understanding of "truth."

Let me try to restate...  All our tests previously linked with the
shared library.  Some tests were what I call auto-tests.  They no longer
link because main() was removed from the shared library.  I had to
change the makefile so that the tests were compiled with a LINKER flag. 
After making that change, they built and ran.

My argument is not that the tests do not run after making the changes...
it is that I SHOULD NOT HAVE TO MAKE THE CHANGES.  And, if there are
changes to be made, it is wrong to have the shared and static use cases
so different.

I understand on windows there is a huge issue with shared/static
libraries.  Fine.  I don't have to deal with that.  Why do *nix users
now have to worry about dynamic/shared issues they never had to deal
with before?  I understand you are trying to make the library more
consistent for users of multiple platforms.  I can appreciate that. 
however, your changes have simply made them very odd and unconventional
for *nix users.

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

Which means a change to makefiles also...  and it also means you have to
static link all tests.  Tests should be run as both static and dynamic
linked to ensure both libs are tested.  Also, as mainline development, I
only want tests compiled against shared libs.  The linking is much
faster, and the space is far less.  For final testing, tests are built
agains static and dynamic libs.

> That's because you did not define BOOST_TEST_DYN_LINK.

I feel like I beating the same drum.  I never had to define that macro
before.  Now, to get my auto-tests to properly link, I have to define it
when the test modules are compiled.  Compiling application source files
based on how they will be linked is unacceptable to me.

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

OK...  but that blasted BOOST_TEST_DYN_LINK is now required, when I've
never had to use it for anything before.

You said this is a common boost practice.  What is it used for then,
besides building shared libraries, or doing something on windows?

> 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 

Right.  Unfortunately, most of our tests were written using the manual
registration.  I don't remember back that far, but I imagine the
auto-registration either didn't work as we thought, or was not available
in 1.29, or we were simply unaware of it.  In any event, we have a ton
of tests written that way.

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

Yes, that's correct.

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

Hmmm.  That's what we did, and it "worked."  We couldn't find anything
telling us how it should be done, so we tried that, and it seemed to
work.

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

Since I'm not an expert at windows DLLs, I have to answer NO.

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

I can accept that.  I can even accept that we need to change our tests. 
What I can not accept is the implementation of the solution.

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

We have to add the DYN_LINK command to auto-tests, and we have lots of
manual registration tests, and the solution is anything but benign.

I'd MUCH rather see it either fully contained in both liraries (like
before), or completely gone from both libraries.

In my opinion, half baked or not, the previous solution worked.  The
current soultion, where you have to compile differently whether you use
the static or dynamic library is the half baked one...