RcppArmadillo with macOS and OpenMP In a Post R 4.0.0 World

[coatless]

From Simon:

we are now building with macOS 10.13 (High Sierra) as target (i.e. the oldest supported system), regular Apple Xcode/command line tools and GNU Fortran 8.2. R builds are running on macOS 10.15 (Catalina) with Xcode 11.4 using macOS 10.13 target. Packages are built on macOS 10.13 VMs with just Apple command line tools (this should make it easy to replicate the setup using Travis, for example). All 3rd party libraries that CRAN uses are available in http://mac.r-project.org/libs-4/

Source: https://stat.ethz.ch/pipermail/r-sig-mac/2020-April/013289.html

This means that macOS is no longer supporting a compiler compatible with OpenMP by default. So, custom compilations of RcppArmadillo will be required to enable OpenMP. I don't think that RcppArmadillo will be affected by this change as it already disables OpenMP when which clang returns an Apple identifier.

RcppArmadillo/configure.ac

Line 74 in 284d318

apple_compiler=$($CXX --version 2>&1 | grep -i -c -e 'apple llvm')

Though, that should be verified on an r-devel build of macOS.

[eddelbuettel]

Thanks. Can you merge this with the pinned #268 / update the pinned #268 accordingly?

[eddelbuettel]

Any update / closure / recommendation for the docs regarding the macOS setup ?

[coatless]

Yes, we do have an update!

OpenMP can be re-enabled by grabbing libomp and setting up compilation flags from http://mac.r-project.org/openmp/

However, macOS users will never be able to use it with RcppArmadillo because even with re-compiling RcppArmadillo from source the configure.ac will detect the apple llvm string and disable it.

We'd need to do some further tinkering with detection in configure.ac to enable it. Not sure it's worth it...

[eddelbuettel]

Yes, thanks I think I saw one post on that (maybe I was tagged). So good to have that.

And agree that tinkering with configure.ac may not be worth it... All this changes too often.

[kevinushey]

I can make one suggestion: configure.ac could check whether OpenMP support is available by default; that is, check whether one can compile a program using OpenMP with "plain" compiler flags. That would basically be a way of checking that "the user seems to know what they're doing"; that is, they've enabled OpenMP by default and RcppArmadillo doesn't need to do anything special.

I proposed this for data.table here:

Rdatatable/data.table#4374

and the PR has been accepted but not yet merged.

I'd be willing to contribute something similar for RcppArmadillo if there is interest.

[eddelbuettel]

That's good. Doing an actual build is better than just (globally) inferring from platforms defaults.

Especially on a platform as, how do I say this charitably?, "challenging" as you're preferred one.

The only other counter-argument would be to to maybe trust the R default configuration. But I could also see that a user may override after the fact for package builds...

[eddelbuettel]

So data.table does this in a shell script configure. We are back at autoconf for RcppArmadillo (having done both in the past). Compiling snippets is pretty standard here too.

What I am wondering is where to do it. Just the macOS case? We are doing fine otherwise 'trusting' R to hand us -fopenmp where available.