Hi folks, is somewhere documented how to add automake/autoconf stuff for boost to a project? I have a set of small testcases and the need boost_unit_test_framework-gcc library to compile. At the moment I add the lib directly to linker options with project_test_LDADD = -lboost_unit_test_framework-gcc But this is not platform independent, because someone might have not gcc installed. So how can I do it in a better way? Sebastian
is somewhere documented how to add automake/autoconf stuff for boost to a project? I have a set of small testcases and the need boost_unit_test_framework-gcc library to compile. At the moment I add the lib directly to linker options with
project_test_LDADD = -lboost_unit_test_framework-gcc
But this is not platform independent, because someone might have not gcc installed. So how can I do it in a better way?
The way to put in libraries is to AC_CHECK_LIB them. That will check that the lib is present with the given test symbol, and will link to it in the final build. -- Petri Latvala
Petri Latvala wrote:
is somewhere documented how to add automake/autoconf stuff for boost to a project? I have a set of small testcases and the need boost_unit_test_framework-gcc library to compile. At the moment I add the lib directly to linker options with
project_test_LDADD = -lboost_unit_test_framework-gcc
But this is not platform independent, because someone might have not gcc installed. So how can I do it in a better way?
The way to put in libraries is to AC_CHECK_LIB them. That will check that the lib is present with the given test symbol, and will link to it in the final build.
-- Petri Latvala
I didn't see any Boost Autoconf macros in the ac-archive http://ac-archive.sourceforge.net/ nor in Peter Simon's Autoconf archive http://www.gnu.org/software/ac-archive/. And since I haven't run across such macros anywhere else, I offer some Armchair Autoconf'ing. I do not know if the following is executable. AC_SEARCH_LIBS(...) might do it handily. You'd list the variant library names in the second argument. This would select the first library found; limited, but not bad for a first cut. Or you could probably find part of the library name (compiler) in the CXX variable, and then use it in AC_CHECK_LIB. Either approach could be made more flexible by adding appropriate '--with-<~boost-option>' flags to configure.ac to help construct the target boost library name(s). Regards, -- Vince Virgilio
On Thu, Jun 24, 2004 at 10:32:20PM -0500, Vincent N. Virgilio wrote:
Petri Latvala wrote:
is somewhere documented how to add automake/autoconf stuff for boost to a project? I have a set of small testcases and the need boost_unit_test_framework-gcc library to compile. At the moment I add the lib directly to linker options with
project_test_LDADD = -lboost_unit_test_framework-gcc
But this is not platform independent, because someone might have not gcc installed.
Worse; in boost 1.31, there are now *four* pieces of build variant information encoded in the library name: toolset, threading, runtime, and version (http://www.boost.org/more/getting_started.html#Results).
AC_SEARCH_LIBS(...) might do it handily. You'd list the variant library names in the second argument. This would select the first library found; limited, but not bad for a first cut.
Yeah, but with four variant pieces, the combinatorics really work against this approach. I don't know how you'd guess the boost version to use, for example.
Either approach could be made more flexible by adding appropriate '--with-<~boost-option>' flags to configure.ac to help construct the target boost library name(s).
This is probably your only real option: introduce a "--with-boost-variant" option so that the installer can specify the variant to use, i.e. the "toolset-threading-runtime-boostversion" string. For the Debian boost packages, by the way, we introduced an extra symlink for each library that DOES NOT HAVE the variant information included. We can do this because the canonical debian packages produce only a single variant for each library. Thus you can simply link using "-lboost_unit_test_framework" on Debian. If other packagers adopt this approach, it becomes feasible for an autoconf macro to fall back to the "un-varianted" library name. -Steve
Steve M. Robbins
For the Debian boost packages, by the way, we introduced an extra symlink for each library that DOES NOT HAVE the variant information included. We can do this because the canonical debian packages produce only a single variant for each library. Thus you can simply link using "-lboost_unit_test_framework" on Debian.
What about boost itself? I think they also use boost test for testing the boost lib. So they may already have some macros? Sebastian -- http://www.hpfsc.de/ - die Seite rund um: Assembler, Bundeswehr, TFT LCDs, Halle/Saale, Fahrradtouren, Neuseeland, Wanderstaat Mauma, Raumschiff USS Nathan, Enemy Room, MLCAD Tutorial
On Fri, 25 Jun 2004 05:01:56 +0300, Petri Latvala wrote:
is somewhere documented how to add automake/autoconf stuff for boost to a project? I have a set of small testcases and the need boost_unit_test_framework-gcc library to compile. At the moment I add the lib directly to linker options with
project_test_LDADD = -lboost_unit_test_framework-gcc
But this is not platform independent, because someone might have not gcc installed. So how can I do it in a better way?
The way to put in libraries is to AC_CHECK_LIB them. That will check that the lib is present with the given test symbol, and will link to it in the final build.
Unfortunately, the Boost unit-test framework is a strange beast. AC_CHECK_LIB will check that the lib is present by writing a small main() which calls the supplied function; but boost_unit_test_framework already defines a main(), and requires the user to supply a function with signature test_suite* init_unit_test_suite( int argc, char* argv[] ) Therefore, AC_CHECK_LIB is doomed to fail. Presently I'm trying to use lower-level macros such as AC_LINK_IFELSE. I'll post something if I succeed... Later, Luigi
participants (5)
-
Luigi Ballabio -
Petri Latvala -
Sebastian Stein -
Steve M. Robbins -
Vincent N. Virgilio