CMake: Don't use libraries in /usr/local by default on macOS

qmake builds of Qt don't use libraries in /usr/local because the
path is not considered a system path. Only the SDK path should be
used as a source of system libraries.

We should do the same for the CMake builds, which involves a couple of
things.

Tell CMake not to consider /usr/local (and a bunch of other
paths) as system prefix paths.

Disable pkg-config usage which by default is not used in qmake
Windows and macOS builds.

If a user wishes to use libraries located in /usr/local on macOS, they
can explicitly enable the behavior via -DFEATURE_pkg_config=ON.

In addition to enabling pkg-config, that will also disable the system
prefix modification described above.

Implementation notes

To disable pkg-config usage, we set an empty path for
PKG_CONFIG_EXECUTABLE, because there is no other good way. The
downside to this is that a lot of warning messages will be printed
that the pkg-config package can not be found.

The pkg-config feature needs to be computed in QtBuildInternals before
qtbase/src/configure.cmake, because it's too late to do it in that
file where a few qt_find_package calls already exist.
The feature value is also saved to QtBuildInternalsExtra, to make sure
that pkg-config is disabled whenever building another repo.

System prefix adjustment is done by removing paths from
CMAKE_SYSTEM_PREFIX_PATH.
Ideally we would remove also /usr as a path, to match what qmake does,
but that breaks find_program() calls for perl, python, etc.

We have to make sure that qt_find_package does not look in
PATH when looking for packages, which is the default behavior, because
PATH on macOS most likely contains /usr/local.

One last curiosity for future generations is that CMake 3.18+ has
merged a change to prioritise SDK locations over regular /usr/lib.

Fixes: QTBUG-85261
Change-Id: I28fe5bae7997507a83b37b4eb1e0188e64062c57
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>

0 files changed, 0 insertions, 0 deletions