On Wed, 16 May 2007 11:14:26 -0400 "Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote:
"Jody Hagins" <jody-boost-011304@atdesk.com> wrote in message news:20070516092500.59f0ebd0.jody-boost-011304@atdesk.com...
On Wed, 16 May 2007 02:41:08 -0400 "Gennadiy Rozental" <gennadiy.rozental@thomson.com> 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...