"Ilya Sokolov" <fal_delivery@mail.ru> wrote in message news:fko5dv$g8l$1@ger.gmane.org...
Gennadiy Rozental wrote:
"Ilya Sokolov" <fal_delivery@mail.ru> wrote in message news:fkg1cd$gdv$1@ger.gmane.org...
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?
1. Because alternatively I would've required 90% of the users to define 2 pretty closely names macro: BOOST_TEST_MAIN to define init function (this is what this macro always did, so I can't change the meaning)
In my opinion, BOOST_TEST_MAIN is a misleading name because it produces not only the main() function.
It is a bit. Now. But you should understand the history. First of all this macro primary puspose is to produce init function (not function main(), so you got quite the opposite "because"). Initially test module init function was considerred a replacement for the function main(), since the fnction main itself was part of the library. And BOOST_TEST_MAIN was intended to generate empty one. Later on during dynamic library support update it functionality was increased t oactually produce the function main(). I don't see ths as a big problem. In most cases it's still clear what it means - it designate test file as containing test module entry point.
plus another one BOOST_TEST_MAIN_FUNCTION that will actually produce the function main()
2. Unfortunately original test modult function signature is unacceptable for DLL initialization. So i had to introduce new one.
I don't see it unacceptable, given the majority of init_unit_test_suite() functions using BOOST_TEST_SUITE macro. I think
See my other post. It has nothing to do with BOOST_TEST_SUITE macro
BOOST_ALTERNATIVE_INIT_API should be default, but not the requirement for dynamic builds. And maybe it should be default for static builds also, because now it is recommended to use "master test suite".
Quite the opposite: I can't be default and it is a requirement for the dynamic builds. And again it has nothing to do with master test suite interface.
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); } No. I don't think this is the best approach. Much better (and shorter) solution is
struct init { init() { boost::filesystem::initial_path(); } }
BOOST_GLOBAL_FIXTURE( init );
I see this much cleaner:
#ifdef BOOST_TEST_DYN_LINK # define BOOST_TEST_MAIN_FUNCTION #endif
Where this maro is used?
#include <boost/test/unit_test.hpp>
bool init_unit_test() { boost::filesystem::initial_path(); return true; }
What if you need to to some cleanup as well? What if you need to do multiple initialization bits that reside in different test files? What if all your test units are automatically registerred - init function definition will require function main as well if you intend to use shared library.
Now if I want to support using static Boost.Test, I am forced to define BOOST_TEST_ALTERNATIVE_INIT_API.
I always find it confusing: why would you want to support both static and shared libraries?
Why not???
Why yes?? From my prospective it's misgueded effort, sinse most of the time you select one usage fariant and stick with it.
Pick one more convinient for you and stick with it. It's not like you need to test your test module with all variants of Boost.Test framework. It's your own test, not the test for the UTF. All in all I find an effort for simultanious support for both static and shared variant of the UTF a bit misguided.
I want to seamlessly migrate from static UTF to shared. I need to fallback to the static UTF where it is not supported (by toolchain).
Where? The primary direction of my effort was to make sure shared library works consistently on all platforms. If you still insist on static/shared library compartibility it can be achieved: define BOOST_TEST_NO_MAIN and BOOST_TEST_ALTERMNATIVE_INIT_API during library compilation and you got what you need. Genadiy