Discussion about minimum Qt5 version in #13478.

utACK ec16f4a.

Build error:

checking for QT5... no
configure: WARNING: Qt dependencies not found; bitcoin-qt frontend will not be built

This would be a nice to have cleanup/simplification. I've tested on macOS 10.13.5, building with Qt 5.11.1:

ec16f4a:

However, there are a couple issues:

This PR isn't the place to discuss it, but I'm currently Concept NACK on adding per platform Qt minimums. I'll continue that discussion in #13478.

As pointed out above, the macOS Travis build is currently failing. I've verified locally using a native depends build:

checking for Qt5Core Qt5Gui Qt5Network Qt5Widgets Qt5MacExtras... no
configure: WARNING: Qt dependencies not found; bitcoin-qt frontend will not be built
checking whether to build Bitcoin Core GUI... no (Qt5)

The issue is that we aren't currently including macExtras with qt in depends, so if we want to do this our qt package will need to be updated.

Also, if this change is going to force the macOS Qt minimum to be 5.2, can you drop this Qt VESION check:

@fanquake - Thanks. Was looking into the Qt package when you commented. I'll pick up the conversation at 13478 and update this PR as necessary.

Concept ACK

@droark Have you had a chance to follow up here?

@fanquake - Hi. I started working on some depends stuff and then got distracted. I'll pick it up ASAP. I'll see if I can optimize any more Mac-specific code but that might take a little longer. In the meantime, I've rebased.

Note that this patch will force the bitcoin-qt binary to have a minimum of Qt 5.2 on Macs due to usage of QtMacExtras

That's acceptable.

@droark Are you planning on continuing this? Otherwise II'll label as "Up for Grabs". \

The 5.2 requirement is no longer an issue, as master currently requires >5.4 anyways. The plan for 0.18 will likely be a minimum required version above 5.2 regardless.

@fanquake - Yes, I'm still on it. I was just waiting to see what was decided regarding Qt (i.e., 5.4 minimum). I'll rebase it right now and look into the failures from there.

Added a new commit that incorporated feedback. I also removed QtMacExtras. As best I can tell, trying to cross-compile Qt "extras" packages isn't a good idea. I did an end-run by just copying the code for QtMac::toNSImage() and modifying as necessary.

Hmmm. Still getting an error when cross-compiling. In particular, toCGImage() still requires QtMacExtras, and the underlying code seems to tap into a private Qt API that we have no business using. (Besides, it fails as-is.) This PR may need some rethinking. Anybody have any ideas? The cleanest thing to do would be to cross-compile QtMacExtras. I'm just not sure it's doable, or sane if it is doable. If not, this PR will probably have to be withdrawn, or radically reworked. The current method, while inefficient, manages to avoid extraneous Mac-specific libraries.

• qt: Cleanup MacDockIconHandler class #14597 (qt: Remove old MacDockIconHandler class by hebasto)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

@DrahtBot - Thanks. I'll look at that PR more closely. At a glance, it should be a cleaner merge, so I'll probably work around that one (assuming my PR can be salvaged, per my posts above).

@droark Given that #14597 removes the entire macdockiconhandler.mm file, I'm not sure there'll be much to salvage (code wise) here. I'm going to close this for now, if it turns out this is still needed, i.e 14597 falls through we'll reopen. If you've got further macOS depends related, please open a new PR.