Data.table: [Request] اختبار توافق المترجم مع "-fopenmp" قبل استخدام "SHLIB_OPENMP_CFLAGS"

تحظر هذه المشكلة حاليًا استخدام data.table على نظام Mac مع إصدار التطوير R ، والذي بدوره يحظر عددًا من الحزم الأخرى ، وبالتالي تطوير وتحديث الحزم:

> 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   

فقط لاحظ أن هذا لا يزال يسبب مشاكل (على سبيل المثال هذه المشكلة الجديدة في مجتمع R) ، خاصة بعد إصدار جديد عندما لم يقم CRAN ببناء ثنائي بعد. الآن بعد أن كنت تستخدم برنامجًا نصيًا للتكوين (https://github.com/Rdatatable/data.table/pull/3951) ، قد يكون من المفيد إضافة هذا الاختبار إلى نص التهيئة ، لذا سيعمل التجميع مع سلسلة أدوات macOS الأصلية (وإن كان ذلك بدون الموازاة).

jimhester شكرا على الملاحظة. اعتقدت أنه يعمل بالفعل مع المجمعين بدون openmp ، وهذا محدد في CRAN_Release.cmd هنا: https://github.com/Rdatatable/data.table/blob/b2d618ce291a50872e10fc1ca7137faa8484005a/.dev/CRAN_Release.cmd#L183. لكن من الواضح أنني مخطئ وهذا لا يكفي. سأحاول فهم ما تقوله وتقترحه.

أشعر بالإحباط بعض الشيء من ادعاءات المستخدمين بأن data.table يحظر أي شيء. إنها مشكلة MacOS ... لماذا لا تتضمن openmp افتراضيًا؟ كل هذا يعمل بسلاسة على نظامي Linux و Windows.