Opened 9 years ago

Closed 4 years ago

#49303 closed defect (fixed)

qt4-mac: Update to 4.8.7_2 Breaks CMake

Reported by: digitalriptide@… Owned by: michaelld (Michael Dickens)
Priority: Normal Milestone:
Component: ports Version: 2.3.4
Keywords: Cc: mkae (Marko Käning), thomas.gimpel@…, rubendibattista (Ruben Di Battista), RJVB (René Bertin), mojca (Mojca Miklavec), anddam (Andrea D'Amore)
Port: qt4-mac

Description (last modified by ryandesign (Ryan Carsten Schmidt))

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.

Change History (25)

comment:1 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

Description: modified (diff)
Owner: changed from macports-tickets@… to michaelld@…
Summary: Update to 4.8.7_2 Breaks CMakeqt4-mac: Update to 4.8.7_2 Breaks CMake

comment:2 Changed 9 years ago by 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!

comment:3 Changed 9 years ago by 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!

comment:4 Changed 9 years ago by 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.

comment:5 Changed 9 years ago by mkae (Marko Käning)

Cc: mk@… added

Cc Me!

comment:6 Changed 9 years ago by thomas.gimpel@…

Cc: thomas.gimpel@… added

Cc Me!

comment:7 Changed 9 years ago by rubendibattista (Ruben Di Battista)

Same thing happens with avidemux

#49220

comment:8 Changed 9 years ago by rubendibattista (Ruben Di Battista)

Cc: rubendibattista@… added

Cc Me!

comment:9 Changed 9 years ago by 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.

comment:10 Changed 9 years ago by AlD (Daniel Albers)

Michael, see #49314 :)

comment:11 Changed 9 years ago by 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.

comment:12 in reply to:  10 Changed 9 years ago by michaelld (Michael Dickens)

Replying to daniel@…:

Michael, see #49314 :)

Fixed in r141516.

comment:13 in reply to:  11 Changed 9 years ago by 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.

comment:14 in reply to:  4 Changed 9 years ago by 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..

comment:15 Changed 9 years ago by 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.

Last edited 9 years ago by burr2@… (previous) (diff)

comment:16 in reply to:  9 Changed 9 years ago by 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 port also complains during configure that it 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
Version 0, edited 9 years ago by clarkjc260@… (next)

comment:17 Changed 9 years ago by mkae (Marko Käning)

Cc: rjvbertin@… added

comment:18 Changed 9 years ago by mojca (Mojca Miklavec)

Cc: mojca@… added

Cc Me!

comment:19 Changed 9 years ago by 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.)

comment:20 in reply to:  19 Changed 9 years ago by 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.

comment:21 Changed 9 years ago by anddam (Andrea D'Amore)

Cc: and.damore@… added

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.

comment:22 Changed 4 years ago by michaelld (Michael Dickens)

Is this still an issue for CMake 3.18.0?

comment:23 Changed 4 years ago by RJVB (René Bertin)

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

comment:24 Changed 4 years ago by 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.

comment:25 Changed 4 years ago by michaelld (Michael Dickens)

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.