Suggestion: perhaps re-arrange the OpenMP install options for macOS, putting `gfortran` as option 1, `llvm` as option 4?

Open
#4,903 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
45/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Stale
Tech stack
r
Domain
documentation

Research direction

Open the data.table wiki's Installation page and inspect Step 2 of the "OpenMP enabled compiler for Mac" section. Review the existing compiler options and the context from issue #4899, then clarify the preferred ordering before editing. Done means the macOS install instructions present the agreed compiler choice first and accurately explain the options.

Written by the indexing model from the issue text.

Description

documentation install platform-specific
Recommendation in the macOS install docs

Perhaps move the gfortran up to option 1, perhaps llvm towards the bottom. Or whichever compiler is often used by those who develop the package towards the top. (This would be Step 2 of the "OpenMP enabled compiler for Mac" section). That way newbs like me are more likely to end up using the compilers most used by the experts. Defaults / order matters!


I'm a bit of a novice when it comes to compilers. Literally because the llvm option was first and appeared to work (or has historically), I tried that. Those "defaults" have stayed.

We're it not for my adventures outlined in #4899, I would not have know how much the compiler mattered. I just assumed if it successfully compiled an installed (no matter the compiler e.g. llvm vs gfortran) then things were fine.

That is not the case.

Could just be a fluke with the version of llvm I used. But woof, what a nightmare two days that was—and I almost lay the blame on data.table, my most favorite package!

Dominant language
R
Stars
3.9k
Forks
1.1k
Avg merge
14h 4m
Merged PRs (30d)
4

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Rdatatable/data.table

All issues in Rdatatable/data.table

Similar issues

More R issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.