Make it easier to use homebrew packages for some libraries
Needs ReviewPublic

Authored by arichardson on Mar 22 2018, 11:14 AM.

Details

Summary

There is now an option [Homebrew]/Enabled that can be used to toggle use
of homebrew packages on MacOS. It defaults to true if the brew command is
found and false if it isn't. If enabled we add the gettext, libarchive and
openssl@1.1 library and include directories to
CMAKE_LIBRARY_PATH/CMAKE_INCLUDE_PATH/PKG_CONFIG_PATH so that cmake finds
the libraries. It also prepends the bison/bin directory to $PATH since the
system one is too old.

It also introduces an experimental option [Hombrew]/qt which can be set in
order to use Qt5 from homebrew. If it is set to "disabled" (default) the
current behaviour is kept. Otherwise it can be set to a given version (such
as 5.10.0) so that $(brew --cellar qt)/5.10.0/bin is used to find qmake.
It can also be set to "latest" to use whatever is the latest version that
has been installed by homebrew.

Diff Detail

Repository
R138 Craft
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
arichardson requested review of this revision.Mar 22 2018, 11:14 AM
arichardson created this revision.

I personally would prefer this not go in craft for many reason:

  • Some homebrew packages are specificly built for a partilar macos version
  • Some homebrew packages might depends other hombrew libraries, making hard to handle the complete dependency tracking for create stand alone package
  • I alreayd started work to make craft agnostic of homebrew (or anything like it) - ie, adding support for pkg config, cmake, bison, flex..., and low level libraries, see https://github.com/pasnox/craft-blueprints-kde/commits/master

My patches may require some small refactoring, but coupled with hanna in progress package overriding, it will then be extremely easy to build kde for mac without any external dependency, reducing complexity and dependency tracking of externals artifacts.
I would then prefer we continue to correctly polish the on going work, and don't rely on such package manager.

I fully agree with all of your points.

However, if I am not building packages but just trying to compile a KDE project locally I would quite like to be able to use the homebrew version of Qt5. The other libraries probably don't really matter since they can be built very quickly.
Maybe the better approach is to try and extend the QtSDK options (although I yet understand the implementation of it) to also work with homebrew Qt5?

well actually craft should work with libs/qt5.ignored and an existing qmake in your path