Data.table: [Demande] Testez la compatibilité du compilateur avec `-fopenmp` avant d'utiliser `SHLIB_OPENMP_CFLAGS`

Ce problème bloque actuellement l'utilisation de data.table sur Mac avec la version de développement de R , qui à son tour bloque un certain nombre d'autres packages, et à son tour, le développement et la mise à jour des packages :

> sessionInfo()
R Under development (unstable) (2017-05-26 r72742)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS Sierra 10.12.5

Matrix products: default
BLAS: /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.0.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets 
[6] methods   base     

loaded via a namespace (and not attached):
[1] compiler_3.5.0 tools_3.5.0   

Juste une note que cela pose toujours des problèmes (par exemple ce nouveau sur la communauté R), en particulier après une nouvelle version lorsque CRAN n'a pas encore construit de binaire. Maintenant que vous utilisez un script de configuration (https://github.com/Rdatatable/data.table/pull/3951), il peut être utile d'ajouter ce test au script de configuration afin que la compilation fonctionne avec la chaîne d'outils macOS native (mais sans parallélisation).

@jimhester Merci pour la note. Je pensais que cela fonctionnait déjà avec des compilateurs sans openmp, et c'est vérifié dans CRAN_Release.cmd ici : https://github.com/Rdatatable/data.table/blob/b2d618ce291a50872e10fc1ca7137faa8484005a/.dev/CRAN_Release.cmd#L183. Mais clairement je me trompe et ce n'est pas suffisant. Je vais essayer de comprendre ce que vous dites et suggérez.

Je suis un peu frustré par les affirmations des utilisateurs selon lesquelles data.table bloque quoi que ce soit. C'est MacOS qui pose problème... pourquoi n'inclut-il pas openmp par défaut ? Tout fonctionne sans problème sous Linux et Windows.