Building against the Mac SDK caused issues in software that can't deal with
conditionally supported APIs. This happened e.g. in as liblzma which was
linking against a symbol present only starting with macOS 10.12 even though
the deployment target is set to 10.11. I added a workaround for this but it
turns out that this breaks other software.
It seems like the better solution is to just build against the files and
libraries in /usr and ensure that the CI system is running the oldest
supported version of macOS.
Pulling in headers from /usr/local/include is not an issue on the CI system
since /usr/local is almost empty. However, it can cause issues when building
on a system that has lots of programs installed using homebrew (and the
corresponding libraries and headers in /usr/local).
Normally /usr/local/include is at the beginning of the system search dirs.
To avoid pulling in libraries from homebrew and then failing to link because
/usr/local/lib is at the end of the library search list we now add
/usr/include to the beginning of the system header search dirs using -isystem
instead.
This should hopefully be less fragile that building against the SDK. The
old approach of using the XCode SDK is still available but disabled by
default. It can be enabled using MacSDK/Enabled=True in the config file.