Gennadiy Rozental wrote:

"Vladimir Prus" <ghost@cs.msu.su> wrote in message news:200611081912.10638.ghost@cs.msu.su...

...

Just a quick question: is it still true that Boost.Test libraries cannot be DLL on Windows?

No. DLL Support is implemented. Boost.Test Jamfile is updated also to support this

Ok, then few more questions 1. What are the instructions for using Boost.Test DLL on Windows? Some experiments results in:         ### mwld Linker Error:         #   Undefined symbol: '_main'         #   referenced from '_mainCRTStartup' in maincrt.c:97         (MSL_All-DLL_x86_D.lib) ..failed cw.link ..\..\..         \bin.v2\libs\test\test\class_properties_test.test\cw-9.4\debug\class_properties_test.exe... 2. Do you plan to update FAQ, that still says it's not implemented (at least on HEAD). 3. Are there any plans to modify the testsuite so that linking to DLL is tested? Thanks, Volodya

"Juergen Hunold" <hunold@ivembh.de> wrote in message news:200611082043.27180.hunold@ivembh.de...

...

No. DLL Support is implemented. Boost.Test Jamfile is updated also to support this

But not Jamfile.v2

Yes. That's right. I know nothing about Boost.Build V2 and never supported second file.

Please find test_build.Jamfile.v2 attached for enabling shared linking using msvc and defining "BOOST_TEST_DYN_LINK=1" on all platforms for shared linking. This makes the behaviour consistant on all platforms which means you'll get similar errors on all platforms... And also adding the missing usage requierements without nothing will work at all :-))

You also need to use <dll>... instead of <lib>.... I think

...

1. What are the instructions for using Boost.Test DLL on Windows?

Here are some extracts from docs I an working on: Building dynamic library First let's clarify that by dynamic library here (and further in the documentation) we mean dynamically loaded library (alternatively it's also called shared library). To build dynamic library you need to add BOOST_TEST_DYN_LINK to the list of defines in makefile. Note that the same flag BOOST_TEST_DYN_LINK needs to be defined during test module compilation for it to successfully link with dynamic library. ... The supplied test runners Design the supplied test runners is based on rationale to simplify users experience in most common cases. No wonder result is a bit contrived, right ;)? The "source" of the complications is the word "common" above. Let's consider different usage scenarios and the options the UTF supply in each case. a.. The UTF is built as static library and linked with test module built as executable or "included" version of UTF is used b.. The UTF is built as dynamic library and linked with test module built as executable c.. Both UTF and test module are built as dynamic libraries In many regards the test runner implementations works similar in all the cases. For example return code generation follows the same logic. You will notice in next section though that usage choice affects also required interface of test module initialization routine. Static library or "included" Framework Statically build version on the UTF and "included" header supply the test runner in a form of free function unit_test_main with the following signature: int unit_test_main( int argc, char* argv[] ); In addition in default configuration the test executable entry point function main() is supplied that does nothing more than just invoke test runner function. In case if this is for any reason undesirable you need to define flag BOOST_TEST_NO_MAIN during build (either library in case of static library or the executable itself in case of "included" version). If you compare with the dynamic library case you will notice that you don't need to supply test module initialization routine as an argument to this function. Instead it's defined as an external function with fixed name in user's code. Dynamic Library Dynamically build version on the UTF supplies the test runner in a form of free function unit_test_main with the following signature: int unit_test_main( bool (*init_unit_test_func)(), int argc, char* argv[] ); Unlike static library case, function main() implementation couldn't reside in a library code for portability reasons. Instead it's supplied as part of unit_test.hpp header and included in case if BOOST_TEST_MAIN or BOOST_TEST_MODULE flags are defined during compilation, while BOOST_TEST_NO_MAIN is not. Notice that if multiple test files in test module include unit_test.hpp, BOOST_TEST_MAIN/ BOOST_TEST_MODULE should be defined only in one of them. Also in this case you need to supply the pointer to the initialization routine as an argument to the test runner function (since in general case dynamic library implementation couldn't have any undefined symbols reference). ... Test module initialization There are two tasks that may need to be done by users before actual testing could start: 1.. Test tree need to be built (unless you are using automatic registration facilities) 2.. Any custom user initialization needs to be performed. That includes initialization of the code under test and custom tune-up of the UTF parameters (for example log or report output streams redirection). The UTF dedicate single function for this purpose called test module initialization routine. Alternatively in you could employ global fixtures. For more details, including differences in two approaches, check the fixtures section. The UTF require the test module initialization routine to be defined be the users. In case if static library or included version is used, the UTF enforces both function signature and function name. In case if dynamic library is used only function signature is enforced by the UTF in general case. But supplied test runners also enforce the same function name (as the one required by former case) in case if you wish to auto-generate function main() body. In many cases you don't need to do any custom initialization and test tree construction is automated. In this case you don't really need the initialization function and the UTF provides a way to automatically generate empty one. In older versions of the UTF the test tree construction was always manual. Later versions introduced an ability to employ automatically registering test cases and test suites. In new design original initialization function signature became inconvenient and unnecessary unsafe. So an alternative initialization function signature was introduced. This change is not backward compatible though. So for now the UTF is still using original initialization function signature by default. To switch to use alternative new one you need to define BOOST_TEST_ALTERNATIVE_INIT_API both during static library build, if you choose to have one, and during test module build. The plan for the next release is to switch default from the original to new signature. Ultimately old initialization function signature will be deprecated and removed. Original (default) initialization function signature and name In original design of the UTF user is required to implement the function with the following specification: boost::unit_test::test_suite* init_unit_test_suite( int argc, char* argv[] ) While this function was originally designed to initialize and return master test suite, in current version of the UTF the result value of this function is ignored and accordingly null value is not considered to be an error. So don't return constructed test suites. Instead register them in master test suite using regular test suite add interface. The only way to report initialization error is to throw a framework::setup_error exception. Pair of arguments argc, argv presents command line arguments specified during test module invocation. It's guarantied that any framework-specific command line arguments are excluded. Alternative initialization function signature and name In alternative initialization design the UTF user is required to implement function with the following specification: bool init_unit_test() The result value of this function indicates whether or not initialization was successful. To register test cases or test suites in a master test suite use regular test suite add interface. To access command line arguments use framework::master_test_suite().argc and framework::master_test_suite().argv. It's guarantied that any framework-specific command line arguments are excluded. Note that this interface for runtime parameter access is temporary. It's planed to be updated once runtime parameters support rework is completed. Automatic generation of test tree initialization function To automatically generate empty initialization function you need to define BOOST_TEST_MAIN before including boost/test/unit_test.hpp header. The value of this define is ignored. Alternatively you could define BOOST_TEST_MODULE to be equal to any string (not necessarily in quotes). This macro will cause the same result as BOOST_TEST_MAIN, and in addition the value of this macro will became the name of the master test suite. Note though that for test module consisting from multiple test files you need to define theses macros only in a single file. Otherwise you will generate multiple instances of the initialization function. Dynamic Library Due to some portability limitation users of dynamically build library are required to employ new alternative initialization function signature. BOOST_TEST_MAIN/BOOST_TEST_MODULE flags still could be used to generate empty instance of initialization function. Notice though that these flags also govern inclusion of function main default implementation into test file body. It means that if you wish to implement either of them manually, you couldn't define above flags and are required to implement both function main() and initialization function (on plus side: in this case you are not required to comply to initialization function name).

My main questions: - Is it really necessary to have two different setup method for Boost.Test ? One for shared and one for static linking ?

In short - yes

- can we provide a (maybe special) target which will automagically provide a "main" when linking to the shared libraries ?

Please read above and let me know if your questions still persist. Gennadiy

Gennadiy Rozental wrote:

Attached see version of class_properties_test.cpp that works both with static and dynamic libs

Thanks, this appears to work. Do you plan to commit it to CVS? - Volodya

Hi Gennadiy ! On Thursday 09 November 2006 21:08, Vladimir Prus wrote:

Gennadiy Rozental wrote:

...

Attached see version of class_properties_test.cpp that works both with static and dynamic libs

Yes, because it uses the AUTO_TEST framework. All other AUTO_TEST based tests in the whole boost work with static and dynamic linked UTF. That's not the deal :-(( My main problem is that I've got tests using the _old_ API (add test per test_suite->add(new custom_test_suite). And the Boost tests use them, too. See my patch to Volodya making them explicitly link to the static UTF libraries... And from all I've read I see no easy way of switching those _transparently_ from static to dynamic linking and back. By _tranparently_ I mean _without_ changing the sources (quite a lot) and adding some macros... Or I've still not understood the docs. I'll think I'll simply try all possible combinations of makros and test-frameworks and just create a test suite showing everything that works and what will not work... Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de

Gennadiy Rozental wrote:

...

And from all I've read I see no easy way of switching those _transparently_ from static to dynamic linking and back. By _tranparently_ I mean _without_ changing the sources (quite a lot) and adding some macros...

No. It's not transparent. But it's not that complecated either. Give it a try and let me know how did it work out for you. Once you switched to an alternative init API the only difference in dynamic/static compilation is function main in your test module.

I think the problem here is for Boost tests itself. Now, large number of them does not work with shared linking. So, I'm about to commit Juergen's patch that explicitly makes all Boost test link to static version of Boost.Test. I think this is a temporary solution. For one thing, dynamic linking will reduce the size of binaries considerably, so I think making all tests work with shared Boost.Test is something to do for the next release. How to make all library maintainers make the switch is a big question though ;-) - Volodya

"Vladimir Prus" <ghost@cs.msu.su> wrote in message news:ej01q8$207$1@sea.gmane.org...

Gennadiy Rozental wrote:

Gennadiy Rozental wrote:

...

"Juergen Hunold" <hunold@ivembh.de> wrote in message news:200611082043.27180.hunold@ivembh.de...

...

...

No. DLL Support is implemented. Boost.Test Jamfile is updated also to support this

...

But not Jamfile.v2

Yes. That's right. I know nothing about Boost.Build V2 and never supported second file.

...

Please find test_build.Jamfile.v2 attached for enabling shared linking using msvc and defining "BOOST_TEST_DYN_LINK=1" on all platforms for shared linking. This makes the behaviour consistant on all platforms which means you'll get similar errors on all platforms... And also adding the missing usage requierements without nothing will work at all :-))

You also need to use <dll>... instead of <lib>.... I think

Not in V2.

...

...

...

1. What are the instructions for using Boost.Test DLL on Windows?

Here are some extracts from docs I an working on:

Building dynamic library First let's clarify that by dynamic library here (and further in the documentation) we mean dynamically loaded library (alternatively it's also called shared library). To build dynamic library you need to add BOOST_TEST_DYN_LINK to the list of defines in makefile. Note that the same flag BOOST_TEST_DYN_LINK needs to be defined during test module compilation for it to successfully link with dynamic library.

...

...

Dynamically build version on the UTF supplies the test runner in a form of free function unit_test_main with the following signature:

int unit_test_main( bool (*init_unit_test_func)(), int argc, char* argv[] );

Unlike static library case, function main() implementation couldn't reside in a library code for portability reasons. Instead it's supplied as part of unit_test.hpp header and included in case if BOOST_TEST_MAIN or BOOST_TEST_MODULE flags are defined during compilation, while BOOST_TEST_NO_MAIN is not. Notice that if multiple test files in test module include unit_test.hpp, BOOST_TEST_MAIN/ BOOST_TEST_MODULE should be defined only in one of them.

Does BOOST_INCLUDE_MAIN work as well?

No. I know nothing about BOOST_INCLUDE_MAIN.

Also:

1. What about prg_exec_monitor? It's built as DLL by Jamfile, what are the usage conditions for it?

These were extracts from UTF docs. Check prg_exec_example_dll.vcproj for example and check docs for Program Execution Monitor in cvs.

2. Why test_exec_monitor is provided only as static library?

This component is deprecated and I do not do further development for it.

...

...

- can we provide a (maybe special) target which will automagically provide a "main" when linking to the shared libraries ?

Please read above and let me know if your questions still persist.

It think the question is still reasonable. Can you have *static* library called unit_test_framework_main that would contain the stock definition of the 'main' function?

I am not sure I understand: static version of the UTF does have function main() implementation included. Gennadiy

"Vladimir Prus" <ghost@cs.msu.su> wrote in message news:ej197n$iu1$1@sea.gmane.org...

Gennadiy Rozental wrote:

...

...

It think the question is still reasonable. Can you have *static* library called unit_test_framework_main that would contain the stock definition of the 'main' function?

I am not sure I understand: static version of the UTF does have function main() implementation included.

Yes, but I mean that it's possible to have:

- UTF, that is build either as static lib or DLL and does *not* have any main function. - Small static library that contains stock definition of main.

No. This is not going to be acceptable IMO.

So, when using UTF DLL, user must "just" link to an extra library, which might be simpler than defining macroses.

Why? How is it easier?

And importantly, Boost.Build V2 can make this transparent for all Boost.Test users inside Boost.

Not everybody are using Boost.Build. IMO the issue is not that significant. In a long term Boost.Test users should switch to auto generated test tree and this case is easily supported in both builds. Conversion in 95% of the cases is straightforward and simple to do. Gennadiy

"Vladimir Prus" <ghost@cs.msu.su> wrote in message news:ej2f2f$p32$1@sea.gmane.org...

...

...

Yes, but I mean that it's possible to have:

- UTF, that is build either as static lib or DLL and does *not* have any main function. - Small static library that contains stock definition of main.

No. This is not going to be acceptable IMO.

Why? Is there some problem I've overlooked?

It's unacceptable for Boost.Test users outside of Boost.

...

...

So, when using UTF DLL, user must "just" link to an extra library, which might be simpler than defining macroses.

Why? How is it easier?

Adding one library to link link is easier that modifying sources for a every test program.

There still a change that needs to be done in either Jamfile or source file

...

...

And importantly, Boost.Build V2 can make this transparent for all Boost.Test users inside Boost.

Not everybody are using Boost.Build.

I was talking about Boost.Test users inside Boost; of them all use Boost.Build.

Yes. But Boost.Test is used outside of Boost either

...

IMO the issue is not that significant. In a long term Boost.Test users should switch to auto generated test tree and this case is easily supported in both builds. Conversion in 95% of the cases is straightforward and simple to do.

Sure, but I if nobody does nothing, then in a year from now most tests in Boost will still be linking to Boost.Test statically.

My point is that we couldn't make this change in general. That doesn't mean that we couldn't introduce something boost internals specific. Gennadiy

Hi Gennadiy ! On Wednesday 08 November 2006 21:14, Gennadiy Rozental wrote:

"Juergen Hunold" <hunold@ivembh.de> wrote in message

...

But not Jamfile.v2

Yes. That's right. I know nothing about Boost.Build V2 and never supported second file.

Ok.

You also need to use <dll>... instead of <lib>.... I think

As Volodya mentioned, V2 takes care of thos details...

...

My main questions: - Is it really necessary to have two different setup method for Boost.Test ? One for shared and one for static linking ?

In short - yes

Okay. It's mostly Win32 dll linking which messes things up. Nothing we can do about that.

...

- can we provide a (maybe special) target which will automagically provide a "main" when linking to the shared libraries ?

Please read above and let me know if your questions still persist.

I've read your draft and it contains much more information than the current docs. But I'm still confused which macros I have to use for which use-case. I think that a small table and some minimal examples (tests?) would be much more helpful than long explanations. I'll think and do some experiments over the weekend. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de

"Thomas Witt" <witt@acm.org> wrote in message news:ej0id9$s4t$1@sea.gmane.org...

Gennadiy Rozental wrote:

...

"Juergen Hunold" <hunold@ivembh.de> wrote in message news:200611082043.27180.hunold@ivembh.de...

...

...

No. DLL Support is implemented. Boost.Test Jamfile is updated also to support this

...

But not Jamfile.v2

Yes. That's right. I know nothing about Boost.Build V2 and never supported second file.

That is unfortunate. Boost Build v2 is the *only* build system that will be shipped with 1.34.0.

I planned to learn it after I am done with docs. Gennadiy

Hi Volodya ! On Thursday 09 November 2006 21:14, Vladimir Prus wrote:

Juergen Hunold wrote:

...

My patch does this. I've patches for all other libraries, which simply add "/<link>shared" to the test libraries (see thread_test.Jamfile.v2.diff)

Did you mean "/<link>static"?

Of course :-)) My Kids were keeping me busy yesterday ;-))

And you've only attached a patch for threads. Can you send the patch for all the other libraries too?

Attached. I hope I've deleted all other stuff laying around here from the full diff :-)) If we only had subversion... :-(( I you take a close look, you'll see at least three or four different ways Boost.Test libraries are referenced in the Jamfile.v2's. I think we should aim to make this uniform for 1.35 ... Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de