Enable OpenMP support for CRAN Mac binaries

[grantmcdermott]

At present, CRAN's Mac binary builds of fixest don't enable OpenMP support. This is pretty well documented in other issues around the repo, where our current workaround advice is for users to configure their .R/Makevars and install from source if they want multi-threaded performance.

However... it turns out that CRAN has actually supported binary MacOS builds with the OpenMP runtime enabled since R 4.3.0. I know of several packages taking advantage of this service, including data.table. (See @kevinushey's initial PR here: Rdatatable/data.table#6034)

The key thing is to make CRAN's build system aware of OpenMP detection in order to enable the appropriate compiler flags.

This PR steals borrows the same basic configuration that data.table uses to enable the same out-of-the-box OpenMP runtime support for fixest. The solution basically involves shipping a configure script that actively detects OpenMP availability. This configure script:

• Tests for OpenMP support using platform-specific flags
• Generates appropriate src/Makevars based on detection results
• Falls back gracefully to single-threaded build if OpenMP unavailable

Testing

Local testing shows the configure script works correctly:

$ R_HOME=/Library/Frameworks/R.framework/Resources ./configure
* checking if R installation supports OpenMP with "-Xclang -fopenmp" ... yes

I would also suggest that we submit a version to CRAN's MacOS builder, but @lrberge should probably do that as the listed maintainer.

Expected Impact

After this change, CRAN's Mac binary builds should include OpenMP support, giving Mac users the same multithreaded performance as other platforms without requiring source installation.

Refs

• R CRAN macOS OpenMP documentation
• data.table OpenMP fix PR #6034

[grantmcdermott]

Okay, I've updated the configure script to handle the clang17/Xcode 16.3+ OpenMP runtime incompatibility (following the approach laid out by the data.table devs here: Rdatatable/data.table#7318).

As I understand it, the main change is that the OpenMP test now compiles, loads, and executes a test shared library, rather than just checking compilation. This basically just means that the script will detect any broken R-bundled runtime and cascade through several fallbacks until it finds one that works.

Tested locally on my local machine: macOS arm64 with Apple clang 17.0.0 (Xcode 16.4) + R 4.5. The R-bundled -lomp correctly fails the runtime check, and the script falls through to /usr/local/lib/libomp.dylib which works. getFixest_nthreads() gives me 7 threads after installation, which is what I'd expect. 🚀🚀

@lrberge as discussed, I recommend submitting this fork to CRAN's MacOS builder and seeing that everything passes. Assuming it does, then I'm pretty confident that we can merge and add a NEWS item saying the multi-threading for MacOS users should now work out of the gate 🤞

[lrberge]

Thanks Grant! I'll check this as soon as I can. That would be a fantastic addition! I keep you updated.

[lrberge]

Hi Grant, on MacOS builder with your version, I get this:

• checking whether package ‘fixest’ can be installed ... [36s/19s] OK
• used C++ compiler: ‘Apple clang version 17.0.0 (clang-1700.6.3.2)’
• used SDK: ‘MacOSX14.4.sdk’
• checking installed package size ... INFO
  installed size is 14.2Mb
  sub-directories of 1Mb or more:
  R 2.0Mb
  doc 4.6Mb
  libs 6.4Mb

=> we're good to go then, right?

[grantmcdermott]

=> we're good to go then, right?

Yes, I think so. Let me add a NEWS item quickly and then we can merge.