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

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-05-17 15:48:08

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

Becasue it's a requirement of portable development. These flags exist for 
every library that employs standalone compilation.

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

I got lucky and don't have to worry about 8nix/NT portability. But this is 
not the case for many others. But i am open to your proposition how address 
these portabiltiy issues differently.

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

Now I must be missing something. If you prefer to avoid any code changes all 
you need to do is for the test modules that employ automated registration 
define BOOST_TEST_DYN_LINK in makefile (which you should have done in a 
first place anyway). And for the test modules that employ manual 
registration make sure in makefiles that they link with static library 
instead. You can do this either by changing library name or adding -static 
flags somewhere in command line. Now all your test modules should work fine.

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

What from above sugestion you call "crazy hoops"?

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

Which statement? There were several. One was "automated facilities are not 
removed, but more powerfull"

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

Ok. And flag like this is required by any boost library for portable linkage 
with dynamic library.

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

My argument is that due to lack of propoer docs (which is totally my fault) 
you misused this configuration previosly. It happends to show up with next 
release, which started to make use of some of the expected dofferences.

> 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. The change was driven by portability considerations. As for "odd and 
unconventional" it's matter of opinion. You don't ususally jump from static 
to dynamic library all the time. Consider this a UTF requirement if you 
opted to use shared library, you need to comply to particular init function 
interfacess and implement function  main() manually. Did you see an example 
in previos post? Do you think the interface is "odd and unconventional"?

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

Why? Are you testing UTF or your own code? Stick to one variant that works 
best for you and use it.

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

If you goal to use shared library you can move to it incrementally. Switch 
test modules that employ manual registration to static libs for now.  Later 
on you either switch to automated registration (which is direction you 
should strive to go) or start using proper interfaces required by dynamic 
library variant.

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

This is a reality of portable development. if you see diferent options lets 
hear it. Usually it's not a problem at all. You stick to one variant and use 
it everywhere.

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

Read "standalone library compilation guidelines".

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

Show me an example. BOOST_TEST_MAIN causes empty init function generation, 
which should obviosly interfere with your own one.

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

What specifically you don;t like in dynamic library variant implementation?

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

The UTF is trying to be as helpfull as possible. For static library variant 
it's possible to put function main() inside the library. And the UTF does 
that. For dynamic library variant you can't do this portably. But UTF tries 
to automatically generate function main() in case if you are using automated 
facilties. Otherwise it's your reponsibility.

The problem the way I see it is that you for some reason trying to test the 
same test module using both static and dynamic variant. I personally do not 
see any reason to do this, unleess you are testing how the UTF itself works.

Gennadiy