The build system uses the GNU Autotools and libtool. All platform-/compiler-dependent parameters should go into the configure.ac file that is processed by Autoconf. The configure script accepts a few non-standard arguments. The most interesting ones to non-developers are:
--enable-backend. This setting will detect the SIMD backend automatically from the C compiler characteristics. Preprocessor macros expected to be predefined by the compiler are inspected, and determine which backend to use. The macros __MMX__, __SSE__, __mips_loongson_vector_rev, __ARM_NEON__, __SSE2__, __SSSE3__, __VEC__, __ALTIVEC__ and __VADMX__ are checked in that order, and the last one in that list found to be defined, wins. If no backend is found, no vector implementation is used. This is a bit different from naming a specific backend, where required SIMD-enabling compiler options are passed automatically.
doxygenprogram is present.
For the full set of options, use
Each directory with source files has its own Makefile.am file that is processed by Automake. All local variables defined in these files are prefixed with
RB_ for RAPP Build, to avoid accidental clashes with Automake variables.
When the RAPP library is built, several convenience libraries are built and merged to form the final library. The
compute/vector directory is a bit special. It is built two times from the same sources, resulting in two different convenience libraries. The first time it is built with no extra flags, producing an implementation using the SWAR vector backend. The second time we define RAPP_USE_SIMD to build a version with the SIMD backend instead. At the top level of the Compute layer, all three implementations (generic, SWAR and SIMD) are combined into the Compute layer convenience library. The function selection mechanism guarantees, if used correctly, that a function is only implemented once.
The build system in the
benchmark directories are a bit special. When the configure script is run, it will check for the presence of an up-to-date pre-tuned configuration file directory. If found, a symbolic link
compute/tune/rapptune.h is created to this file. During build time, this symbolic link will be used for selecting the appropriate implementations. The file benchmarkplot-<host>-<backend>-<wordsize>.html in the
benchmark/arch directory is handled analogously. The symbolic links are only removed on distclean. The
-<wordsize> part, corresponding to the word size used by the platform, is empty for the default size for the platform.
If the pre-tuned rapptune-<host>-<backend>-<wordsize>.h is present but the set of tuned functions has changed since it was generated, the default build behaviour is to generate a new tuning. Alternatively, with an explicit
--enable-tune-cache option, untuned fallback values will be used to fill in the missing tuning numbers, but compiler warnings will be emitted for each such untuned function when building RAPP. This is of course not recommended, but may be useful e.g. when cross-compiling and the target system is not available for tuning at the time RAPP is built.