-
- Downloads
[Autotools] Add new configure test for Threading Building Blocks
dune-common now tests for TBB by default. As TBB has a rather "unique" way of handling installation (it doesn't do it), the test uses the tbbvars.sh environment setup script generated during the build process to locate the library. Stuff is further complicated by the fact that the library names depend on the type of build. Oh joy... So, here is how to use it: --with-tbb=/path/to/tbbvars.sh tells the script where to find the correct version of the library. Unfortunately, there are two different kinds of tbbvars.sh scripts: There is a global one in TBB_DIR/bin (don't use that one) and there are per-build-type versions in TBB_DIR/build/some_path_encoding_the_build type. You need to point the test at one of those (depending on whether you want the debug or the release version). If you omit the option or just say --with-tbb, the script assumes that the headers and libraries can be found somewhere in the default system paths (might be useful when using Intel icc). When --with-tbb is used and the library cannot be found, configure aborts with an error. If the path to the tbbvars.sh script is not passed on the command line, the test will also look at the environment variable TBBVARS_SH. --enable-tbb-allocator links to the tbb_malloc library in addition to the main tbb library, which gives access to the thread-scalable allocator in TBB. Defaults to yes. --enable-tbb-rpath causes the script to try and encode the location of the TBB libraries into the rpath of any generated libraries or programs. This is mainly a convenience feature to avoid having to update (DY)LD_LIBRARY_PATH if TBB is in some non-standard location. You can't get around the shared libraries with TBB (well, you can with some tricks, but upstream *strongly* advises against doing so because you can easily shoot yoursel in the foot. So better only do that on very large machines where the dynamic loader overhead would kill you otherwise). The outcome of the test resembles most other tests in DUNE. If it succeeds, it defines - the preprocessor macro HAVE_TBB to ENABLE_TBB - the preprocessor macro HAVE_TBB_ALLOCATOR to ENABLE_TBB if --enable-allocator is yes - the preprocessor macro HAVE_TBB_PREVIEW to ENABLE_TBB if the community preview features are enabled - the automake conditional TBB - TBB_{CPPFLAGS,LDFLAGS,LIBS} to the appropriate values. Moreover, TBB_CPPFLAGS also defines ENABLE_TBB to 1. In short, to use TBB you have to set up your program / library to be built with TBB_{CPPFLAGS,LDFLAGS,LIBS} and you can enable/disable the build with the automake conditional. Some minor points: - the exact preprocessor flags required depend on the type of build (release / debug and whether or not the community preview features are enabled). - when TBB is enabled, the test also adds -pthread to the CPPFLAGS to make sure that the compiler doesn't use non-reentrant versions of system functions.
m4/tbb.m4
0 → 100644
Please register or sign in to comment