qgis3-dev and Qt 5.8/5.7 incompatible formulae about homebrew-qgisdev

[dakcarto]

Essentially, there is no way to do brew update and currently achieve a viable QGIS 3 build (that I know of).

You can think of Homebrew as being an 'unstable' class of Linux package repository. Often, formulae versions are upgraded (or not) with consideration for other Homebrew formulae, but not for third-party formulae or anything that uses Homebrew for dependencies, which is an OK policy that Homebrew had to establish. This is why the OSGeo4Mac repo contains compatibility formulae, like for building QGIS 2.x.

However, there appears to be no intention on the part of the Homebrew maintainers to fix the inherent stability flaws with Homebrew, i.e. at least create an unstable branch. The usual response is that it helps force projects to keep their code current. This is somewhat OK (as an excuse for not heavily redesigning Homebrew), but not when two or more projects come into conflict with each other, e.g. QGIS 3 can build off of Qt 5.8, though the formulae in question are not updated until a 'more important' project is updated to work with Qt 5.8 first.

At which point, it becomes a Homebrew maintainer's prerogative as to what happens next. So, we are in a holding pattern.

[timlinux]

@dakcarto I really appreciate you trying to get this sorted out. Is there any way to pin versions of home-brew packages like apt has? Also what about maintaining our own archive of all the dependent recipes we use and only upgrading them if they represent a known good configuration?

[m-kuhn]

The issue linked above was closed upstream, is there still something blocking the update to 5.8?

Not to forget, I noticed your work upstream, @dakcarto , thanks a lot for also clearing obstacles there. I don't know what the mac builds would do without you !

[dakcarto]

@timlinux and @m-kuhn, finally was able to update qgis3-dev to support Qt 5.8.0 (see latest commits).

Couple issues:

• You have to hit return (or other keys) twice to get past blocking splash screen (definite regression in Qt 5.7.x --> 5.8.0): https://bugreports.qt.io/browse/QTBUG-57706
  There may be a hidden dialog behind the splash screen that the keystrokes are interacting with.
• Now defaults to using the Ninja CMake generator, mostly because I am completely blocked on some weird issue when using Makefiles, where including any extern "C" headers in qgsgrass.h always fails to find the headers, regardless of C[XX|PP]FLAGS having the correct -I<path/include>.

[timlinux]

Ah thanks @dakcarto I just updated my build deps here yesterday. I will grab the latest changes and test. We are testing building with CLion here too - my build works but it is actually crashing with an unknown exception during startup resulting in a hanging splash. I wonder if that is a similar symptom that you are getting in your blocking splash issue...

[Gustry]

You have to hit return (or other keys) twice to get past blocking splash screen (definite regression in Qt 5.7.x --> 5.8.0): https://bugreports.qt.io/browse/QTBUG-57706
There may be a hidden dialog behind the splash screen that the keystrokes are interacting with.

Yes, I have this dialog I have to close it twice. It doesn't give any information.

[timlinux]

@dakcarto when I press enter twice I get a crash immediately after...

[timlinux]

See #27

[dakcarto]

Hi @timlinux, @m-kuhn and @Gustry. Thanks for the quick testing!

Yeah, this is what I am seeing too, but no crashes for me on macOS 10.11.6 with 'normal' .app double-clicks or running from Qt Creator. However, definitely lots of crashes when trying to run ctest (btw, I added a new qgis-dev-ctest.sh env wrapper script).

@Gustry the dialog in your screen snap is the one seen during ctest runs, and appears to be the same bug noted in https://bugreports.qt.io/browse/QTBUG-57706

@m-kuhn ctest runs are so bad right now on macOS that I need to include a --timeout n option. Still a ways off before Travis CI for macOS can be brought back online.

[m-kuhn]

@dakcarto I don't think we need to be able to run the complete suite successfully right now. We can just blacklist whatever fails and at least make sure we don't get worse on the other tests. Then we can gradually enable the blacklisted tests as we get around to doing this.