I have an R package which is easily sped up by using OpenMP. If your compiler supports it then you get the win, if it doesn't then the pragmas are ignored and you get one core.

My problem is how to get the package build system to use the right compiler options and libraries. Currently I have:

PKG_CPPFLAGS=-fopenmp
PKG_LIBS=-fopenmp

hardcoded into src/Makevars on my machine, and this builds it with OpenMP support. But it produces a warning about non-standard compiler flags on check, and will probably fail hard on a machine with no openMP capabilities.

The solution seems to be to use configure and autoconf. There's some information around here:

http://cran.r-project.org/doc/manuals/R-exts.html#Using-Makevars

including a complex example to compile in odbc functionality. But I can't see how to begin tweaking that to check for openmp and libgomp.

None of the R packages I've looked at that talk about using openMP seem to have this set up either.

So does anyone have a walkthrough for setting up an R package with OpenMP?

[EDIT]

I may have cracked this now. I have a configure.ac script 开发者_如何学JAVAand a Makevars.in with @FOO@ substitutions for the compiler options. But now I'm not sure of the workflow. Is it:

• Run "autoconf configure.in > configure; chmod 755 configure" if I change the configure.in file.
• Do a package build.
• On package install, the system runs ./configure for me and creates Makevars from Makevars.in

But just to be clear, "autoconf configure.in > configure" doesn't run on package install - its purely a developer process to create the configure script that is distributed - amirite?

Methinks you have the library option wrong, please try

## -- compiling for OpenMP 
PKG_CXXFLAGS=-fopenmp
##
## -- linking for OpenMP
PKG_LIBS= -fopenmp -lgomp 

In other words, -lgomp gets you the OpenMP library linked. And I presume you know that this library is not part of the popular Rtools kit for Windows. On a modern Linux you should be fine.

In an unrelease testpackage I have here I also add the following to PKG_LIBS, but that is mostly due to my use of Rcpp:

$(shell $(R_HOME)/bin/Rscript -e "Rcpp:::LdFlags()") \
                              $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)

Lastly, I think the autoconf business is not really needed unless you feel you need to test for OpenMP via configure.

Edit: SpacedMan is correct. Per the beginning of the libgomp-4.4 manual:

1 Enabling OpenMP

To activate the OpenMP extensions for C/C++ and Fortran, the compile-time flag `-fopenmp' must be specified. This enables the OpenMP directive [...] The flag also arranges for automatic linking of the OpenMP runtime library.

So I stand corrected. Seems that it doesn't hurt to manually add what would get added anyway, just for clarity...

Just addressing your question regarding the usage of autoconf--no, you do not want to run autoconf with any arguments, nor should you redirect its output. You are correct that running autoconf to build the configure script is something that the package maintainer does, and the resulting configure script is distributed. Normally, to generate the configure script from configure.ac (older packages use the name configure.in, but that name has been discouraged for several years), the developer simply runs autoconf with no arguments. Before running autoconf, it is necessary to run aclocal, autoheader, libtoolize, etc... There is also a tool (autoreconf) which simplifies the process and invokes all the required programs in the correct order. It is now more typical to run autoreconf instead of autoconf.