GitLab

Christian Rendina authored Jan 04, 2022 and Albert Vaca Cintora committed Jan 04, 2022

Added support for the latest version of Visual Studio (I still left VS2019 as the default one)

This in itself doesn't do much yet, but it enables implementing the
necessary Android-specific adjustments all over the place.

Reviewers: dschmidt, cullmann, fazevedo, arichardson

Differential Revision: https://phabricator.kde.org/D26561

Summary:
MSVC allows co-installing multiple version of the compiler and
vcvarsall.bat will use the latest one by default. This patch adds
a new configuration option that allows user to choose an older toolset
to use.

This is useful when trying to reproduce a build failure against an older
version of MSVC.

Test Plan: Tested locally to force 14.14.26428 toolset while having 14.16.something installed.

Reviewers: vonreth

Reviewed By: vonreth

Differential Revision: https://phabricator.kde.org/D17636

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

Summary:
Should fix the macOS build in T9574

See also https://github.com/Homebrew/homebrew-core/issues/2674 and
https://github.com/Homebrew/homebrew-core/issues/3727 and

Test Plan: Autoconf output for liblzma no longer indicates clock_gettime availability

Reviewers: vonreth, bcooksley, fazevedo, dschmidt

Reviewed By: vonreth

Differential Revision: https://phabricator.kde.org/D15374

This sets the target platform, the compiler falvour, the architectur and
the actual compiler.