-
Alex Richardson authored
Summary: 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. Test Plan: libffi builds for me (no longer using SDK) Reviewers: bcooksley, vonreth, fazevedo Differential Revision: https://phabricator.kde.org/D15401
4ad8b792