Quick notes regarding the approach I mentioned in#170 :

1. This doesnot test for the presence of OpenMP (it's a bit anti-autoconf in nature) but instead tests against compiler version.
2. Just like the prior approach, we do not reconcile the ability of theclang4 binary provided by CRAN to enable OpenMP. (e.g. This fails to detect it.)

I'd feel a bit more comfortable incorporating them4 routineR uses c.f.

https://github.com/wch/r-source/blob/a71d8f00c109a339b40f9ac42d2e9116d986279f/m4/openmp.m4#L34-L100

Results can be found here:

coatless/RcppArmadillo@3f1aed6

devtools::install_github("coatless/rcpparmadillo",ref=" feature/macos-openmp-detection")

I'd love to get Simon's (@s-u) take on why them4 routine is off related to detecting theclang4 OpenMP ability. For another set of eyes let's also ping@kevinushey.

Thanks for your comments.

1. My intention was to detect an OpenMP-compatible clang by version number, similar to the existing gcc check. In the case thatARMA_USE_OPENMP is enabled, but_OPENMP is missing (at compile time), then Armadillo should cover the break, unless I am missing something.

https://github.com/conradsnicta/armadillo-code/blob/unstable/include/armadillo_bits/compiler_setup.hpp#L460

2. I made a minor change to cover theclang4 binary provided by CRAN. Can you check again?

For completeness, I should mention that RcppArmadillo does not use m4 / full autoconf on Linux either. So far we got by 'trusting' R's detection and Armadillo's tests. So I'm not uncomfortable with this approach here either.

So I thinnk we can merge this given the earlier (and largely successful) tests.

Comments?

@conradsnicta - You are correct about the version number. However, the line

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

detects Apple's version and disables OpenMP features. (If this test passes,then we look for a version number.)

@conradsnicta Further, as the R build system is somewhat tight to guarantee success, there tends to be just one version on some OSs (exactly one gcc via R Core / CRAN on windoze; on macOS it is AFAICT one dominating version also from CRAN). But on macOS people can of course shoot themselves in the foot more easily by going via brew (and issue binary API deltas) just as people are wont to do by mixing, say, the anaconda stach with R's which generally results in tears.

For user / developers "who know" we put specific instruction into the FAQ and@coatless cooked up an entire installer script fetching the right version and setting the right hooks.

@conradsnicta And sorry, but I have to get this off my chest once every year: I find it extremely useful that you keep such a close look on what we do here with RcppArmadillo, that you are so responsive to out issues, and that you reach out to us for testing, but I am stillshocked and disappointed that you continue to refuse to mention RcppArmadillo in the Armadillo documentation / links to related software. I asked you at least three or four times, you ignored me each time. I don't get it. As of today468 packages on CRAN use RcppArmadillo but an unknown higher number of github and whatnot projects. Is that not something to share with some pride?

@kthohr for the record, the reason I'm pushing for the OpenMP test to verify the compiler capabilities vs. versioning is because CRAN hosts a crippled version of clang (e.g. no openmp/ libomp-dev).

We ran into this issue circa August 2017. This caused us to move away from theSHLIB_OPENMP_* flag setup to customly setting theOPENMP_FLAGS.

I'd really like to know why theclang4 binary that resulted in the entire toolchain changing isn't been detected as OpenMP-compliant and, thus, providing the benefits of the change.

Also, Brian's clang check fails with

In file included from sparse.cpp:23:
In file included from /data/gannet/ripley/R/packages/tests-clang/RcppArmadillo.Rcheck/RcppArmadillo/include/RcppArmadillo.h:31:
In file included from /data/gannet/ripley/R/packages/tests-clang/RcppArmadillo.Rcheck/RcppArmadillo/include/RcppArmadilloForward.h:46:
/data/gannet/ripley/R/packages/tests-clang/RcppArmadillo.Rcheck/RcppArmadillo/include/armadillo:88:12: fatal error: 'omp.h' file not found
#include <omp.h>
^
1 warning and 1 error generated.

This actually works on my Clang flavor, because I have omp.h from having
installed Debian's libomp-dev. But ideally this test would be
conditional on OMP support?

@eddelbuettel - Nothing related to pride; the arma download page simply aims for providing a deliberate shortlist of directly useful related stuff in pure C++ land, in order to enhance the surrounding ecosystem (this list is short on the download page in order to not overwhelm people with info). This is not necessary with RcppArmadillo, as it is already in a well established ecosystem within R land (with thanks to your hard work).

However, RcppArmadillo is explicitly listed in the Related Software section on Armadillo'sfaq page which is a longer list of software. In fact, RcppArmadillo is linked twice (or three times if you count our nice paper) on arma's faq page -- see also the "Is it possible to use Armadillo from other languages?" question on the Featuressection. I think that's plenty.

If you really want a link to RcppArmadillo on arma's download page, I can put it up, but I just don't see it serving a practical purpose. Someone wanting RcppArmadillo is not going to obtain it from arma's download page anyway -- they will use CRAN and the install_packages() command in R. In fact, having RcppArmadillo listed on the download page can confuse a good chunk of potential users, who may promptly install Armadillo in its pure C++ form (ie standalone library) and then wonder why it's not working in R. I've learned not to underestimate the silly things that people will do.

@conradsnicta Fair points yet I also think RcppArmadillo drives a fair number of visitors to your site, and it would help you too if it had a simple 'for use of Armadillo from the R language see ...' (or alike) link. Anyway, I will berate you more over a beer once I get to Brisbane in July....

So given the thumbs-up reaction in#170, I am merging this.