@MikeMcQuaid: As noted in this comment on #8306, even just having qt be an alias to qt5 has already started causing issues for the small subset of Homebrew users who, prior to said PR's resolution, had the latest Homebrew-delivered instances of both Qt versions 4.x and 5.x installed on their systems. As I stated in the afore-mentioned comment, I, as a member of that small user subset, will submit an issue about this (it would have happened by now, but I kind of got distracted reading the release notes for the stuff I have on my plate to brew upgrade as of today…😆.)

@MikeMcQuaid: As reported by GitHub's notification of #8342's existence and mention of this PR in said issue, said issue is now ready and we can continue discussion of my problem there.

Most of the failures here are due to #8392

Note this is blocked on Homebrew/brew#1770.

This looks to be working. Any objections, folks? I can fix up the minor audit fails when I pull.

And @cartr for final thoughts (and to check you have a pyqt@4 if you want one).

This seems to be incomplete.

iMac-TMP:homebrew-core joe$ ag qt5|grep depend
Formula/cockatrice.rb:23:    depends_on "qt5" => "with-mysql"
Formula/cockatrice.rb:25:    depends_on "qt5"
Formula/color-code.rb:14:  depends_on "qt5"
Formula/gammaray.rb:23:  depends_on "homebrew/science/vtk" => [:optional, "with-qt5"]
Formula/gearboy.rb:15:  depends_on "qt5"
Formula/gearsystem.rb:15:  depends_on "qt5"
Formula/mgba.rb:32:  depends_on "qt5" => :recommended
Formula/qtads.rb:33:  depends_on "qt5"
Formula/quazip.rb:14:  depends_on "qt5"
Formula/qwt.rb:17:  depends_on "qt5"
Formula/qwtpolar.rb:16:  depends_on "qt5"
Formula/qxmpp.rb:15:  depends_on "qt5"
Formula/tarsnap-gui.rb:15:  depends_on "qt5"
Formula/treefrog.rb:23:  depends_on "qt5" => qt5_build_options
Formula/ttfautohint.rb:29:  depends_on "qt5" => :optional
Formula/urh.rb:20:  depends_on "pyqt5"
Formula/wireshark.rb:33:  depends_on "qt5" => :optional
Formula/zurl.rb:16:  depends_on "qt5"

Not sure the extent to which this affects core's formulae, but one issue I've been running into while working on my side of the change is that lots of formulae hard-code Qt's formula name as part of their build process, and that changing the formula name breaks them because they can't find Qt any more. (You may need to bump the revision and re-bottle the dependent formulae.)

It would be worth checking that by installing a bunch of formulae that depend on qt5, switching over to the branch that renames it to qt, then seeing if they still work.

@cartr that is odd. Formulae names are not really exposed to build systems, so the problems you're describing probably have some other cause.

@ilovezfs In this case, I'm pretty sure the formula name is being exposed to the build system of other formulae. Here's my understanding of how it works, at least with Qt 4:

1. When Qt builds, we pass it a path that includes its formula name (e.g. /usr/local/Cellar/qt/4.8.2) as part of the --prefix configure argument.
2. Qt's configure script saves that path into a C++ file that is then built as part of qmake.
3. Other formulae run qmake as part of their build processes to determine where Qt is installed.
4. qmake uses /usr/local/Cellar/qt/4.8.2 as the path to Qt in the Makefiles and -query output it generates, and other formulae end up saving it in config and header files.
5. Formulae attempt to clean this up by using inreplace to replace /usr/local/Cellar/qt/4.8.2 with /usr/local/opt/qt.
6. The fact that Qt 4's opt prefix is /usr/local/opt/qt (and, by extension, that its formula name is qt) gets compiled into other formulae's binaries.

I haven't done super in-depth testing for Qt 5, but I suspect the same is true there, as qmake still has its path compiled in to the binary:

carter@Carter-MBP ~> /usr/local/Cellar/qt5/5.8.0_1/bin/qmake -query
QT_SYSROOT:
QT_INSTALL_PREFIX:/usr/local/Cellar/qt5/5.8.0_1
QT_INSTALL_ARCHDATA:/usr/local/Cellar/qt5/5.8.0_1
QT_INSTALL_DATA:/usr/local/Cellar/qt5/5.8.0_1
QT_INSTALL_DOCS:/usr/local/Cellar/qt5/5.8.0_1/doc
[...]
carter@Carter-MBP ~> strings /usr/local/Cellar/qt5/5.8.0_1/bin/qmake | grep "/usr/local/Cellar/"
qt_epfxpath=/usr/local/Cellar/qt5/5.8.0_1
qt_prfxpath=/usr/local/Cellar/qt5/5.8.0_1
qt_hpfxpath=/usr/local/Cellar/qt5/5.8.0_1
carter@Carter-MBP ~>

@cartr that all sounds normal though, no? Going forward those paths will be /usr/local/opt/qt for qt 5.x and /usr/local/opt/qt@4 for qt 4.x, or have I misunderstood something?

@ilovezfs The issue is that those paths are changing, which will cause any already-built formula that hard-coded them to be wrong.

@cartr right, which is why new bottles for the formulae in the PR will be pulled as well. Are there things missing from the PR that you think need new bottles too?

@ilovezfs Maybe I'm misunderstanding how Homebrew works, but I didn't think brew upgrade re-installed formulae/re-downloaded bottles unless the formula's version number changed. If someone installs a formula that depends on qt5, qt5 gets renamed to qt, and then they run brew upgrade, will it download the new bottle? (What about if the user compiled the formula from source, will Homebrew re-compile it?)

If someone installs a formula that depends on qt5, qt5 gets renamed to qt, and then they run brew upgrade, will it download the new bottles?

Only if we also add or bump the revision.

In this case, there will also be an optlink created for the old name since we're adding an alias "qt5" pointing to the qt formula, so /usr/local/opt/qt5 and /usr/local/opt/qt will both point to ../Cellar/qt/5.8.0_1.

What about if the user compiled the formulae from source, will Homebrew re-compile it?

Also only if there is a revision bump. So you will definitely want to revision bump everything in the qt4 tap after you change the formula name to qt@4 since you won't be able to have an alias "qt" for the formula without directly conflicting with the /usr/local/opt/qt link that points to qt5.

In the case of a formula rename that also has an alias for the old name, there will be an optlink created for the old name, so /usr/local/opt/qt5 and /usr/local/opt/qt will both point to ../Cellar/qt/5.8.0_1.

Ah, I didn't know about that feature. Thanks!

Ah, I didn't know about that feature.

It was recently added. So ordinarily, this would be a less breaking change since you'd have both /usr/local/opt/qt and /usr/local/opt/qt@4 both pointing to the qt4 cellar. But since we're "reclaiming" the qt name and the /usr/local/opt/qt opt link, it'll be particularly important for you to revision bump everything due to the hard coding of paths you described.

Would it be possible to wait a couple of days before merging this? Re-building the binary bottles for my tap will take considerable time on my end.

@cartr you could do it asynchronously by initially pushing revision bumps with the bottle blocks removed, and then re-adding the bottle blocks as the bottles get built.

@ilovezfs I'm aware, but several of the Qt4-related formulae I package have very long build times and I'd like to avoid breaking people's Travis CI builds if possible. After the most-used packages (PyQt, PySide, Qt, WebKit, and their dependencies) are built I'll merge the name change in and we'll be good to go.

@cartr Pushing a new build now and will likely pull when it's working. Apologies that I won't wait; we can't really set a precedent of holding PRs for things in taps we intentionally don't support, sorry 😭.

Thanks for review and help.