Sorry for breaking into discussion but I have a bunch of related questions. Gennadiy Rozental wrote:
"Jens Seidel" <jensseidel@users.sf.net> wrote in message [snip] Because BOOST_TEST_MAIN produces both function main and empty init function. It's assumed that test units are automatically registered.
Why both? Also, why defining BOOST_TEST_DYN_LINK switches on BOOST_TEST_ALTERNATIVE_INIT_API? Suppose I need to perform some initialization call, e.g. boost::filesystem::initial_path(). Currently, with shared Boost.Test I am forced to not to define BOOST_TEST_MAIN and to copy/paste the main() function like this: int BOOST_TEST_CALL_DECL main(int argc, char* argv[]) { return boost::unit_test::unit_test_main(&init_unit_test, argc, argv); } Now if I want to support using static Boost.Test, I am forced to define BOOST_TEST_ALTERNATIVE_INIT_API.
I thought I have also seen a conflict with my own init_unit_test_suite() implementation if I define BOOST_TEST_MAIN but cannot reproduce it.
There would be a compile time error if you follow proper signature of init function for use with shared library.
A question: Would it be save to define BOOST_TEST_DYN_LINK also for static linkage?
No.
I hope so as I have never, really never used different code depending on linker options.
We have to be tollerant to guest from other continents. Our policies selected to work the same way for every one.
Even after renaming my main test_suite* init_unit_test_suite(int, char *[]) function into bool init_unit_test() (but only for dynamic linkage?) as noticed on http://www.patmedia.net/~rogeeff/html/utf/user-guide/initialization.html I fail as usual.
You should see compilation errors now.
Short: In the past it was so simple:
#include <boost/test/unit_test.hpp> using boost::unit_test::test_suite; test_suite* init_unit_test_suite(int, char *[]) { test_suite *test = BOOST_TEST_SUITE("Master test suite"); test->add(BOOST_TEST_CASE(&JacobiTest1)); return test; }
Now I use
* Additional autoconf code to define HAVE_UNIT_TEST_LIB if the (shared?) library is used.
#ifdef HAVE_CONFIG_H #include <config.h> // HAVE_UNIT_TEST_LIB #endif
#ifdef HAVE_UNIT_TEST_LIB # define BOOST_TEST_DYN_LINK # include <boost/test/unit_test.hpp> #else # include <boost/test/included/unit_test.hpp> #endif
1. You can use static library and no need to define BOOST_TEST_DYN_LINK for either library of included variant 2. You can use included variant always 3. You can switch to automated registration and you don't need to define nor function main(), nor init function
using boost::unit_test::test_suite;
bool init_unit_test() { // my old init_unit_test_suite code }
/* int main(int argc, char *argv[]) { init_unit_test_suite(argc, argv); return 0; } */
If you insist on combination of manual registration with shared library, it should look like this:
int main( int argc, char* argv[] ) { return ::boost::unit_test::unit_test_main( &init_unit_test, argc, argv ); }
the required information is wrong and incomplete and addionally
What is wrong?
scattered across multiple pages such as http://www.patmedia.net/~rogeeff/html/utf/compilation.html http://www.patmedia.net/~rogeeff/html/utf/compilation/direct-include.html http://www.patmedia.net/~rogeeff/html/utf/user-guide/usage-variants.html (and all referenced sub pages) http://www.patmedia.net/~rogeeff/html/utf/user-guide/test-runners.html http://www.patmedia.net/~rogeeff/html/utf/user-guide/initialization.html
If you can express it all better I am open to sugestions. It is indeed not very trivial (considering many different usage variant of Boost.Test) to describe all necessary information and be both complete and easily accessible to first timers.
To show you that I really read (at least up to UTF) the documenation I mention a few errors in it:
I'll look on these later.
Thanks for the comments
Gennadiy
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost