qt4-mac: Update to 4.8.7_2 Breaks CMake

[digitalriptide@…]

Updating qt4-mac from 4.8.7_1 to 4.8.7_2 appears to have broken compatibility with the FindQt4.cmake module. Attempting to find Qt4 gives the following error after the update:

CMake Error at /opt/local/share/cmake-3.3/Modules/FindQt4.cmake:1324 (message):
  Found unsuitable Qt version "" from NOTFOUND, this code requires Qt 4.x
Call Stack (most recent call first):

This issue occurs on OS X Mavericks.

[michaelld (Michael Dickens)]

OK. So, can you provide an example port that's broken? Clearly cmake installed, as did qt4-mac. We can't fix broken stuff without knowing what's broken!

[felix.sygulla@…]

Same problem here..

It seems that cmake can not call "qmake", which it uses to retrieve the correct paths to the library. It seems that you moved qmake into libexec/bin, which is not in the PATH by default!

Reproduce by fresh macports install + port install qt4-mac.. then try to call "qmake" from the terminal... won't work

Is there any way to install the port in the old directories? Thanks!

[michaelld (Michael Dickens)]

There are lots of ports that use qt4-mac (and qt5-mac). About 1/2 of them have been verified to work with the new qt4-mac directory, including many that use cmake. Part of the intent behind this move is to allow qt4 and qt5 to be installed at the same time, which means that neither should be accessible by default (without special settings). The way one finds a Qt install is to set the QMAKE and/or QTDIR environment variables. Both are set when one uses the Qt4 or Qt5 PortGroup. The ports having issues thus far have not used this PortGroup and are just setting a dependency on qt4-mac; this technique just won't work.

So, let me say this again: can you provide an example port that's broken? Please start listing them here & we'll get them fixed. Without a list, I can't just go in an start installing arbitrary ports to see if they work or not.

[mkae (Marko Käning)]

Cc Me!

[thomas.gimpel@…]

Cc Me!

[rubendibattista (Ruben Di Battista)]

Same thing happens with avidemux

#49220

[rubendibattista (Ruben Di Battista)]

Cc Me!

[michaelld (Michael Dickens)]

avidemux fxed in r141390. If you come across more of these build issues related to the movement of qt4, add me on CC so that I know & I'll try to get them fixed promptly.

[AlD (Daniel Albers)]

Michael, see #49314 :)

[nihilus (Markus Gothe)]

The problem here is when using cmake outside of the scope of MacPorts so I suggest a fix for the 'FindQt4.cmake'-module.

[michaelld (Michael Dickens)]

Replying to daniel@…:

Michael, see #49314 :)

Fixed in r141516.

[michaelld (Michael Dickens)]

Replying to nietzsche@…:

The problem here is when using cmake outside of the scope of MacPorts so I suggest a fix for the 'FindQt4.cmake'-module.

When using cmake outside of MP, just set the environment variable QMAKE to the correct location -before- doing find_package(qt4 ...). Should be good to go. That's what we do inside MP for all practical purposes & it works nicely. Yes, it's true that this is a slight inconvenience; but, it allows for each parallel install of qt4 and qt5, which is desirable.

[felix.sygulla@…]

Replying to michaelld@…:

There are lots of ports that use qt4-mac (and qt5-mac). About 1/2 of them have been verified to work with the new qt4-mac directory, including many that use cmake. Part of the intent behind this move is to allow qt4 and qt5 to be installed at the same time, which means that neither should be accessible by default (without special settings). The way one finds a Qt install is to set the QMAKE and/or QTDIR environment variables. Both are set when one uses the Qt4 or Qt5 PortGroup. The ports having issues thus far have not used this PortGroup and are just setting a dependency on qt4-mac; this technique just won't work.

So, let me say this again: can you provide an example port that's broken? Please start listing them here & we'll get them fixed. Without a list, I can't just go in an start installing arbitrary ports to see if they work or not.

The problem is really more for builds ouside macports using cmake + qt4. The current setup makes it hardly understandable why qmake is not in the path even though qt4 is installed (and is the only qt version on the system). For our cmake build files I now have to differentiate between qt4 version prior to 4.8.7_2 and 4.8.7_2 with completely different path. That is not very nice and not the idea of installing a package and having all things in known paths.. (at least for builds outside of the macports world). Why can't we keep the first qt version ever on the system installed (e.g. qt4) in the old paths and check if there is already a qt and install the "second" version (e.g. qt5) in the new path? Just a suggestion..

[burr2@…]

The problem and fix for me was that qmake was no longer on my PATH. After adding the path to qmake to my PATH, there were no difficulties. Therefore, this is not necessarily broken, but not working as expected. This fix made Qt4 work with source code using the macports installation of CGAL.

[clarkjc260@…]

Replying to michaelld@…:

avidemux fxed in r141390. If you come across more of these build issues related to the movement of qt4, add me on CC so that I know & I'll try to get them fixed promptly.

The apiextractor and generatorrunner ports also complain during configure that they can't find Qt 4.x.

:info:configure CMake Error at /opt/local/share/cmake-3.3/Modules/FindQt4.cmake:1324 (message):
:info:configure   Found unsuitable Qt version "" from NOTFOUND, this code requires Qt 4.x

[mojca (Mojca Miklavec)]

Cc Me!

[mojca (Mojca Miklavec)]

While Qt4 and Qt5 might live hidden somewhere, I don't see any technical reason why FindQt4.cmake would not be able to find Qt. It's called FindQt4, not FindQt after all. I agree that it's bad if users have to set additional variables when everything could work out of the box. If nothing else we could patch FindQt4.cmake itself to know where to look for files. (Or use René's ideas of packaging Qt.)

[RJVB (René Bertin)]

Replying to mojca@…:

(Or use René's ideas of packaging Qt.)

Much as I appreciate the thought, if you refer to my way installing Qt that doesn't actually provide a solution. qmake still gets installed in ${prefix}/libexec/qt${version}/bin, because Qt itself doesn't really give you any other choice.

Actually, there *is* one aspect of my Qt ports that would indeed help here: both support the port select mechanism to select a default version. I think it was Michael even who suggested I add that feature, way back; I'm not sure why he didn't implement it himself.

technical reason why FindQt4.cmake would not be able to find Qt.

Of course, you can patch FindQt4.cmake. I can give you 2 more or less technical reasons why this is less trivial than it sounds:

• The file is installed by port:cmake; to patch it with complete observation of all principles would mean letting port:cmake depend on port:qt4-mac (at the least it'd have to include the Qt4 PortGroup in order to know where qmake v4 is to be found when installed). This will probably lead to issues building the cmake GUI against Qt5.
• Many ports provide their own FindQt4.cmake ; port:kdelibs4 installs one for all KDE4 ports. You'd have to patch all of them or at least remove the port-specific ones.

[anddam (Andrea D'Amore)]

The reporter and the users' issue seems to be different, the former had a FindQt4.cmake issue that I don't know how to reproduce while the latter cannot access Qt4 binaries from default path.

About the default path issue I see all qt4-mac port's binaries are in $prefix/libexec/qt4/bin/, if qmake is supposed to be run by the user why is it in libexec/ in first place?

If there's a set of binaries that are supposed to be called by the user let's move them to $prefix/bin/ using a suffix and the add qt_select port to solve the default issue.

[michaelld (Michael Dickens)]

Is this still an issue for CMake 3.18.0?

[RJVB (René Bertin)]

Let's assume not, if not only because most users will use the Qt5 gui?

[kencu (Ken)]

cmake seems to work just fine with qt4-mac, and I have not noticed any issues of this nature in several years.

FWIW, I use the qt4 gui on systems < 10.7.

[michaelld (Michael Dickens)]

I have had any issues with cmake +qt4 ... or +qt5 .... so closing this ticket as ‘fixed’ ... sometime ...