Data.table: [Anfrage] Testen Sie die Compiler-Kompatibilität mit `-fopenmp`, bevor Sie `SHLIB_OPENMP_CFLAGS` verwenden

Dieses Problem blockiert derzeit die Verwendung von data.table auf dem Mac mit der Entwicklerversion von R , die wiederum eine Reihe anderer Pakete und damit die Entwicklung und Aktualisierung von Paketen blockiert:

> 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   

Nur eine Anmerkung, dass dies immer noch Probleme verursacht (z. B. dieses neue in der R-Community), insbesondere nach einer neuen Version, wenn CRAN noch keine Binärdatei erstellt hat. Jetzt, da Sie ein Konfigurationsskript (https://github.com/Rdatatable/data.table/pull/3951) verwenden, könnte es sich lohnen, diesen Test zum Konfigurationsskript hinzuzufügen, damit die Kompilierung mit der nativen macOS-Toolchain funktioniert (wenn auch ohne Parallelisierung).

@jimhester Danke für den Hinweis. Ich dachte, es funktioniert bereits mit Compilern ohne OpenMP, und das ist in CRAN_Release.cmd hier überprüft: https://github.com/Rdatatable/data.table/blob/b2d618ce291a50872e10fc1ca7137faa8484005a/.dev/CRAN_Release.cmd#L183. Aber ich liege eindeutig falsch, und das reicht nicht aus. Ich werde versuchen, mir klarzumachen, was Sie sagen und vorschlagen.

Ich bin etwas frustriert über Behauptungen von Benutzern, dass data.table irgendetwas blockiert. Das Problem ist MacOS ... warum enthält es nicht standardmäßig openmp? Es funktioniert alles reibungslos unter Linux und Windows.