stellarium-0.10.0-1 Configure error - wrong QT version used

[simon@…]

On my 10.5.6 system cmake detects the system provided version of QT first and 4.3.1 is too old for Stellarium to build. QT_QMAKE_EXECUTABLE needs to be supplied for cmake to use the macports one. Patch attached.

[simon@…]

Sorry, forgot to bump the revision in the attached patch...

[raimue (Rainer Müller)]

I don't have any Qt framework in the system directories, so I can't reproduce easily. But I am still interested to fix this to avoid problems for others.

Although I have qt4-mac installed, I don't have a qmake-mac binary, only qmake.

port installed qt4-mac stellarium
The following ports are currently installed:
  qt4-mac @4.4.3_0+dbus+docs (active)
  stellarium @0.10.0_1 (active)

What does port provides /opt/local/bin/qmake-mac say?

[simon@…]

I get the following:

simon@moria:~$ port installed qt4-mac stellarium
The following ports are currently installed:
  qt4-mac @4.4.3_1 (active)
  stellarium @0.10.0_1 (active)
}}} {{{
simon@moria:~$ port provides /opt/local/bin/qmake-mac
/opt/local/bin/qmake-mac is provided by: qt4-mac
}}} {{{
simon@moria:~$ ls -al /opt/local/bin/qmake
ls: /opt/local/bin/qmake: No such file or directory

Different binary names would make this harder. Maybe it would be a more portable approach to add qmake-mac to cmake/FindQt4.cmake and only add ${prefix} as QTDIR environment variable in the Portfile.

[raimue (Rainer Müller)]

Upgraded to qt4-mac @4.4.3_1. mcalhoun added the -mac suffix in r44203 to avoid conflicts between qt4-mac and qt4-x11. Stellarium still builds correct for me.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

After I changed how qt4-mac operated (r44214), I attempted to fix the ports which depended on qt4-mac.
The fix for cmake based ports seems not to have been general enough.
All I did was set the QTDIR variable
(r44221, r44218, r44219, r44229, r44220, r44241, r44242, r44225, r44234, r44233, r44232, and r44231).

When FindQt4.cmake tries to find qmake, it searches in the order

FIND_PROGRAM(QT_QMAKE_EXECUTABLE NAMES qmake qmake4 qmake-qt4 PATHS
  "[HKEY_CURRENT_USER\\Software\\Trolltech\\Qt3Versions\\4.0.0;InstallDir]/bin"
  "[HKEY_CURRENT_USER\\Software\\Trolltech\\Versions\\4.0.0;InstallDir]/bin"
  "[HKEY_CURRENT_USER\\Software\\Trolltech\\Versions\\${qt_install_version};InstallDir]/bin"
  $ENV{QTDIR}/bin
)

So QTDIR is the last place that is searched.

Setting QT_QMAKE_EXECUTABLE NAMES explicitly (as was done in the patch) seems to be a better solution.
​FIND_PROGRAM does not search if the variable is already defined.

The problem is most likely not confined to stellarium and would also show up if there were a qmake in ${prefix}/bin
(e.g. from the soon to be finished qt4_select).

I will look into the problem further.

[mf2k (Frank Schima)]

Cc Me!

[mf2k (Frank Schima)]

I was not able to build stellarium, it failed in the config phase as follows:

--->  Configuring stellarium
Error: Target org.macports.configure returned: configure failure: shell command " cd "/opt/local/var/macports/build/_opt_mports_trunk_dports_science_stellarium/work/stellarium-0.10.0" && cmake -DFreeType2_INCLUDE_DIR:PATH=/opt/local/include/freetype2 -DFreeType2_LIBRARIES:FILEPATH=/opt/local/lib/libfreetype.dylib -G "Unix Makefiles" . " returned error 1
Command output: -- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc-4.0
-- Check for working C compiler: /usr/bin/gcc-4.0 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/g++-4.0
-- Check for working CXX compiler: /usr/bin/g++-4.0 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for include files HAVE_BYTESWAP_H
-- Looking for include files HAVE_BYTESWAP_H - not found.
-- Looking for tzset
-- Looking for tzset - found
-- Looking for pow10
-- Looking for pow10 - not found
-- Looking for setlocale
-- Looking for setlocale - found
-- Looking for snprintf
-- Looking for snprintf - found
CMake Error at cmake/FindQt4.cmake:1278 (MESSAGE):
  Qt qmake not found!
Call Stack (most recent call first):
  CMakeLists.txt:78 (FIND_PACKAGE)


-- Configuring incomplete, errors occurred!

Error: Status 1 encountered during processing.

Applying the attached patch allowed me to successfully build it.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Fixed in r44375.

[illogic-al@…]

Adding the -mac suffix was a _really_ bad idea as this breaks a lot more than it fixes. I think there needs to be a better solution to installing qt4-x11 and qt4-mac on the same system. and until there is people should deactivate/activate the one they need before compiling a program.

Right now it creates the problem of one more variable needed for each kde portfile created. and as kde needs uic, maybe uic3 and moc, there's always the chance of having to add 3 more variables should upstream modify their build system for whatever reason.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to illogic-al@…:

Adding the -mac suffix was a _really_ bad idea as this breaks a lot more than it fixes.

I would respectfully disagree with that assertion.
It resolves a conflict between qt4-x11 and qt4-mac.
It takes a step toward avoiding conflict between qt4-* and qt3*.
It might make the transition to Qt 5 easier in years to come.
It brings qt4-mac more in line with the default behavior of Qt (by default Qt tries to install to /usr/local/Trolltech/Qt-4.4.3).

I think there needs to be a better solution to installing qt4-x11 and qt4-mac on the same system.

To me, at least, what we have now seems to be pretty good.
Are there better ideas available?

and until there is people should deactivate/activate the one they need before compiling a program.

Are there any know problems?
If so, I would suggest filling a bug report instead.

Right now it creates the problem of one more variable needed for each kde portfile created.

I am not a maintainer or any kde ports, so forgive me for asking, but is this such an onerous burden?
It is a one time change (my apologies if I failed to make the change in any port).
As a comparison, most python ports have to set configure.python.

and as kde needs uic, maybe uic3 and moc, there's always the chance of having to add 3 more variables should upstream modify their build system for whatever reason.

As far as I can tell, all the ports now require one variable (e.g. QT_QMAKE_EXECUTABLE) to find Qt.
Is there any reason to suspect that number might increase?

[illogic-al@…]

Cc Me!

[(none)]

Milestone Port Bugs deleted