Description
Meson misidentifies early 64-bit Macs as 32-bit. This causes the build systems of other programs that use meson (such as babl) to misbehave or fail on those old systems.
The very first Intel Macs used 32-bit Intel Core processors. On these Macs, uname -m returns i386 as you might expect.
Then Apple switched to 64-bit Intel Core 2 processors, but continued to boot them with a 32-bit kernel. Here, uname -m returns i386 to denote the kernel architecture, though they are happy to run 64-bit user programs. It is these systems on which meson misbehaves.
Later, Apple switched to a 64-bit kernel. In this case, uname -m returns x86_64. I presume it is these Macs on which meson was tested.
On some Intel Macs, whether the 32-bit or the 64-bit kernel is used depends on the macOS version or on user configuration.
Meson's detect_cpu and detect_cpu_family begin by using Python's platform.machine, which gets its value from os.uname().machine, which comes from uname -m.
The problem is that most people are using meson to build regular user software, not kernel extensions. For building regular user software, it is not useful to know the kernel architecture (what uname -m returns); one only needs to know the user architecture.
I don't know how to determine the user architecture using a single command. But, having gotten to the point of knowing that you are on an "i386" processor running Darwin, you could then run sysctl -n hw.cpu64bit_capable; if the answer is 1, it's really an x86_64 processor. Do allow for the possibility that this might fail, since sysctl -n hw.cpu64bit_capable is only available in Mac OS X 10.5 and up. But on 10.5 and earlier, the default build architecture was 32-bit, so misidentifying 64-bit 10.4 machines as 32-bit isn't a huge problem.