"Chris Fairles"
Thanks for the quick reply. I have considered the automated test suite. I guess one reason is that I wanted to be able to tweak the logging formats.
Why don;t you do it at runtime?
Option 1 works, but for some reason I can't figure out how to link in static files using automake heh... SOURCES in Makefile.am doesn't pick up .a's for some reason. Friggen annoying and I scanned their docs all
-dynamic needs tobe added somewhere
day so i'm either blind, or they don't consider it a possibility. I've been considering using boost.build but writing Jamfiles is trial and error pretty much so its very time consuming (docs need a little work).
I'll try option 2 for now. See how it fares.
Cheers, Chris
On 4/30/07, Gennadiy Rozental
wrote: Hi, Chris
1.34. version of Boost.Test made changes in design of the dynamic library based version of the UTF. Since there is no way to portably place function main() in shared library, it had to be moved into the header. You've got 3 options:
1. Switch to the static library variant of the UTF. No changes required in your test module. 2. Use the automated registration facilities and define the macro BOOST_TEST_MAIN/BOOST_TEST_MODULE before boost/test/unit_test.hpp inclusion. In this case both function main() and an empty test module initialization function are generated as part of your test file automatically. 3. If you prefer to keep manually registered test cases and/or need to perform custom test module initialization you will have to comply to the an alternative initialization function signature and implement function main() yourself as direct forward to the test runner supplied with dynamic library variant of the UTF:
bool your_init_func() { // do you initialization here // register you test cases in master test suite: // framework::master_test_suite.add( ... );
return true; // true - init successful, false - otherwise }
int main( int argc, char* argv[] ) { return ::boost::unit_test::unit_test_main( &your_init_func, argc, argv ); }
In both cases 2 and 3 you need to define BOOST_TEST_DYN_LINK. I personally recommend you to consider option 2. You will soon find it much easier to manage and write new test module.
HTH,
Gennadiy
"Chris Fairles"
wrote in message news:fac6bb500704300804g60679f0bk2a2e2f96c50a630c@mail.gmail.com... Testing out boost beta 1.34. I built the whole she-bang with the gcc toolset. I tried compling my unit tests and they all get:
/usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status
I don't use the auto test case mechanism. My tests suites look like:
#include "boost/test/unit_test.hpp" using boost::unit_test::test_suite;
void free_test_function() { BOOST_CHECK(1 == 1); }
test_suite* init_unit_test_suite( int, char* [] ) { test_suite* test= BOOST_TEST_SUITE( "Unit test example 1" ); test->add( BOOST_TEST_CASE( &free_test_function ) ); return test; }
I compile using g++ -Wall -I/usr/local/include/boost-1.34 -o unit_test unit_test_test.cpp -L/usr/local/lib64 -lboost_unit_test_framework-gcc41-mt-d
If i define BOOST_TEST_DYN_LINK either in the cpp file before or after the unit_test.hpp include, or specifify it using -D on the command line I get the same results.
I tried to look through the headers responsible for defining BOOST_TEST_DYN_LINK but theres a lot of references to "msvc auto-linking" which I of course do not use. Should I be defining BOOST_ALL_DYN_LINK ? I recall it not being set somewhere because boost.build v2 doesn't like it or something.
Really i can't make heads or tails of what I should be defining, whether I shouldve defined something when building the unit test libs, or whether I should be defining something building my own. The docs say something about defining BOOST_TEST_DYN_LINK but as stated above, it doesn't seem to make a difference.
Chris
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users