"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.
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
BOOST_AUTO_TEST_CASE
-- 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 presentation: #define BOOST_TEST_DYN_LINK #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 */ ); } bool init_function() { framework::master_test_suite(). add( BOOST_TEST_CASE( boost::bind( &free_test_function, 1, 1 ) ) ); framework::master_test_suite(). add( BOOST_TEST_CASE( boost::bind( &free_test_function, 1, 2 ) ) ); framework::master_test_suite(). add( BOOST_TEST_CASE( boost::bind( &free_test_function, 2, 1 ) ) ); return true; } int 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)...
#define BOOST_AUTO_TEST_MAIN #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 changes. Gennadiy