search

TomHarte / CLK

A latency-hating emulator of: the Acorn Electron and Archimedes, Amstrad CPC, Apple II/II+/IIe and early Macintosh, Atari 2600 and ST, ColecoVision, Enterprise 64/128, Commodore Vic-20 and Amiga, MSX 1/2, Oric 1/Atmos, early PC compatibles, Sega Master System, Sinclair ZX80/81 and ZX Spectrum.
MIT License
931 stars 52 forks source link

Include <cstddef> and use std::nullptr_t not nullptr_t #1314

Closed ryandesign closed 8 months ago

ryandesign commented 8 months ago

Fixes error: use of undeclared identifier 'nullptr_t'; did you mean 'nullptr'? when compiling with Xcode 12.4.

TomHarte commented 8 months ago

I guess this somewhat suggests that additional CI is required? Either way, thanks!

ryandesign commented 8 months ago

I guess this somewhat suggests that additional CI is required?

I wrote the new CI workflow using the matrix syntax that makes it easy to add more OS versions to each job if desired:

https://github.com/TomHarte/CLK/blob/31cbcb206f511743c81a8b1cd16143fc7899fed8/.github/workflows/build.yml#L6-L8

There are several macOS version available on GitHub actions although it's a bit strange at the moment. I wrote your workflow to use ubuntu-latest and macos-latest since then you would not have to update it as new OS versions come out. You would expect "latest" to mean the latest stable version of the OS that is available, however macos-latest currently means macOS 12 which is actually the oldest version of macOS Apple still supports. You could explicitly specify macos-12 instead if you want. macos-13 and macos-13-arm64 are available but I think those runners are still considered beta. Runners for macOS 14, although that is the current stable version of macOS, are not yet available. macos-11, although no longer supported by Apple, is still available. As I understand it, macOS 13 introduced problems for GitHub that required them to switch how they host their CI infrastructure and I guess they haven't fully worked those out yet.

Each macOS image includes several versions of Xcode, for example the macos-11 image has six versions of Xcode available including 12.4 although that is not the default. With some more changes to the workflow, it could be made to select which Xcode version to use. One could go overboard building on every possible combination of Xcode and macOS version and still not cover everything.

Finally, although this PR fixed the build issue I mentioned, an additional build issue remained which is not easily solvable because its cause is a bug in the version of clang bundled with older Xcode. The bug only affects users building on old versions of macOS with correspondingly old versions of Xcode; the bug was fixed in newer versions of Xcode. I can file a separate bug report about that and explain the options, but for now, if we go to the effort of enabling CI that uses Xcode 12.4, it will fail due to this remaining issue.