build failure on MacOS Intel

[jcw]

I'm trying to build the latest code from this repository on MacOS (mpy-cross/ and ports/unix/).
On Mac M1, RasPi Linux 32-bit, and Intel Linux 64-bit it all works as expected (make submodules deplibs, etc).
On the Intel Mac, however, mpy-cross/ builds ok, but ports/unix/ fails with:

$ make
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
mkdir -p build-standard/genhdr
GEN build-standard/genhdr/mpversion.h
GEN build-standard/genhdr/moduledefs.h
GEN build-standard/genhdr/qstr.i.last
modffi.c:32:10: fatal error: 'ffi.h' file not found
#include <ffi.h>
         ^~~~~~~
1 error generated.
Traceback (most recent call last):
  File "/Users/jcw/code/git/micropython/ports/unix/../../py/makeqstrdefs.py", line 188, in <module>
    preprocess()

On this machine, there's a libffi due to dependencies in several homebrew packages:

$ find /usr/local/ -name ffi.h
/usr/local//Cellar/libffi/3.4.2/include/ffi.h
$

On M1, homebrew works differently, and this header file is in a different place:

$ find /opt/Homebrew/ -name ffi.h
/usr/local//Cellar/libffi/3.4.2/include/ffi.h
$

There are instructions in brew info libffi how to export various settings (which I have on neither one).
But that should all be irrelevant, since libffi is a submodule in this repository anyway, I'd assume?
What's puzzling is that – apart from x86 vs arm – these two build environments are basically identical.

Update - in the python3 ../../py/makeqstrdefs.py ... command leading up to this, I see:

-I/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/ffi

Which doesn't exist. Should that perhaps be .../MacOSX12.3.sdk/... ?

Update 2 - when changing 10.15 to 12.3 and running the command manually (and again fix it for CC modffi.c), the build completes properly and produces a functioning executable.

[dpgeorge]

You can disable ffi via make MICROPY_PY_FFI=0.

You can also try building with the provided libffi via make MICROPY_STANDALONE=1 (by default it uses the libffi provided by the system).

[jcw]

Thanks - yep, that first alternative works. The standalone one still generates the same compile error.