Could someone help me with Qt-Celestia?

[Guckytos]

Okay,

Qt-compilation is definitely driving me insane. It won't work for me on whichever OS I try it. Compiling Celestia und Windows with C++ or for Linux runs smoothly as can be.
But whenever I try it with Qt it just results in the compiler exiting.

Just tried it a last time with the following specs:
Celestia: A fresh SVN checkout from today (trunk)
Qt: Windows; fresh download from Nokia "qt-sdk-win-opensource-2010.04.exe"
Machine: a virtual system with just basic Windows XP SP3 and Qt installed, no other software.

Started Qt, loaded the Qt projectfile under celestia/src/celestia.pro, set the build to "release" and let it run until it stopped.

Here is the full log that Qt made during the compilation process. Looks like it stopped due to something in the UI for Qt (as far as I understood).

Qt report file.zip

Hope someone can tell me what the heck I am doing wrong the whole time. So that I can bang my head against either the wall or my desk for being too stupid to notice.
Or write a how-to guide in the Celestia wikibook. That part is missing.

Regards,

Guckytos

[chris]

Christian,

Just to be clear: are you building on Windows with QtCreator? I assume this is what you mean when you say that you started Qt.

--Chris

[Guckytos]

Christian,

Just to be clear: are you building on Windows with QtCreator? I assume this is what you mean when you say that you started Qt.

--Chris

Oooops,

again I was not clear enough.

Yes, I am building on Windows XP SP3 with QtCreator.

[t00fri]

Christian,

if you downloaded and compiled Qt yourself, the configuration of qmake is done automatically.
However, in case you downloaded the compiled Qt library for Windows, you got to copy the
Qt/4.x.y/mkspecs/win32-<your MS compiler>/qmake.conf to Qt/4.x.y/mkspecs/default.


If you forgot about this configuration step, nothing will work, unless you apply special command-line
arguments in qmake calls.

If you use Qt-Creator, you simply must make sure that the correct compiler and the Qt version are
recognized in the configuration dialog of Qt-creator.

Here is a screenshot of how Qt-creator's project page must look like. Note the arguments of the qmake call!


Fridger

[chris]

Christian,

if you downloaded and compiled Qt yourself, the configuration of qmake is done automatically. However, in case you downloaded the compiled Qt library for Windows, you got to copy the Qt/4.x.y/mkspecs/win32-<your MS compiler>/qmake.conf to Qt/4.x.y/mkspecs/default.

I don't think that this is necessary anymore... The MinGW 4.4 compiler is included with the Qt SDK and should just work without any special configuration.

In Christian's compile log, the Qt-generated ui header files are not found, despite the fact that they are getting generated right at the beginning of the compile process. Christian, are the files ui_addbookmark.h etc. present in your build tree? They should be in celestia/src/celestia/qt/ui/. The output in the compile log looks correct:

Code: Select all

c:\Qt\2010.04\qt\bin\uic.exe ..\src\celestia\qt\addbookmark.ui -o celestia\qt\ui\ui_addbookmark.h
c:\Qt\2010.04\qt\bin\uic.exe ..\src\celestia\qt\newbookmarkfolder.ui -o celestia\qt\ui\ui_newbookmarkfolder.h
c:\Qt\2010.04\qt\bin\uic.exe ..\src\celestia\qt\organizebookmarks.ui -o celestia\qt\ui\ui_organizebookmarks.h
c:\Qt\2010.04\qt\bin\uic.exe ..\src\celestia\qt\preferences.ui -o celestia\qt\ui\ui_preferences.h


But for some reasons, the files aren't found they're included... I noticed that the folder celestia/qt/ui is present on the command line, so it should be possible to #include the ui files without the ui/ prefix:

#include "ui_addbookmark.h"

instead of:

#include "ui/ui_addbookmark.h"

But, both should work (and do work on other platforms and compiler configurations...)

--Chris

[t00fri]

The MinGW compiler is optional in the Qt download. I have always avoided to use it.
According to my understanding, It is for people who don't have a MS compiler installed for some reasons. I thought we use the VC++ compilers throughout for Celestia.

Fridger

[Guckytos]

Christian,

if you downloaded and compiled Qt yourself, the configuration of qmake is done automatically. However, in case you downloaded the compiled Qt library for Windows, you got to copy the Qt/4.x.y/mkspecs/win32-<your MS compiler>/qmake.conf to Qt/4.x.y/mkspecs/default.

I don't think that this is necessary anymore... The MinGW 4.4 compiler is included with the Qt SDK and should just work without any special configuration.

Okay guys,

the trouble hunting goes on.

I indeed use the MinGW that is provided together with Qt SDK package. Just to be sure that there are no interferences with any other things. It is optional as you can deactivate it upon installing, but it is a fix part of the SDK.

In Christian's compile log, the Qt-generated ui header files are not found, despite the fact that they are getting generated right at the beginning of the compile process. Christian, are the files ui_addbookmark.h etc. present in your build tree? They should be in celestia/src/celestia/qt/ui/. The output in the compile log looks correct:

Code: Select all

c:\Qt\2010.04\qt\bin\uic.exe ..\src\celestia\qt\addbookmark.ui -o celestia\qt\ui\ui_addbookmark.h
c:\Qt\2010.04\qt\bin\uic.exe ..\src\celestia\qt\newbookmarkfolder.ui -o celestia\qt\ui\ui_newbookmarkfolder.h
c:\Qt\2010.04\qt\bin\uic.exe ..\src\celestia\qt\organizebookmarks.ui -o celestia\qt\ui\ui_organizebookmarks.h
c:\Qt\2010.04\qt\bin\uic.exe ..\src\celestia\qt\preferences.ui -o celestia\qt\ui\ui_preferences.h


But for some reasons, the files aren't found they're included... I noticed that the folder celestia/qt/ui is present on the command line, so it should be possible to #include the ui files without the ui/ prefix:

#include "ui_addbookmark.h"

instead of:

#include "ui/ui_addbookmark.h"

But, both should work (and do work on other platforms and compiler configurations...)

--Chris

Here seems to be the base problem in this case, there is no folder "ui" under "celestia/src/celestia/qt/ui/"!! There is only a folder "celestia/qt/data"! See attached picture of tree structure.
Just to be sure, I just checked svn itself and there is also no folder "/ui" under "celestia/src/celestia/qt".

Folder Tree.png

And for Fridger, this is how my Qt project description looks like.

Qt Build config.png

I hope this helps to clarify things more.

Regards,

Christian

[chris]

Here seems to be the base problem in this case, there is no folder "ui" under "celestia/src/celestia/qt/ui/"!! There is only a folder "celestia/qt/data"! See attached picture of tree structure.
Just to be sure, I just checked svn itself and there is also no folder "/ui" under "celestia/src/celestia/qt".

And for Fridger, this is how my Qt project description looks like.

I hope this helps to clarify things more.

Christian,

The screen shots are very helpful. I noticed that there is a ui folder in celestia-build-desktop. I think that this might be where Qt4 is generating the header files from the ui files. If that's the case, I'll bet that Qt is automatically setting up the compiler flags to look in that folder for the UI header files. We should probably switch from adding the "ui/" to the beginning of the #includes of the UI header files. Can you try making this change for the #includes in qtbookmark.h and see if the build gets a little further? You want to change this:

#include "ui/ui_addbookmark.h"
#include "ui/ui_newbookmarkfolder.h"
#include "ui/ui_organizebookmarks.h"

to this:

#include "ui_addbookmark.h"
#include "ui_newbookmarkfolder.h"
#include "ui_organizebookmarks.h"

--Chris

[t00fri]

Chris, Christian,

I have built the Qt version many times both in Win32 and Linux on different machines, since Celestia-Qt exists. I have many times upgraded the Qt versions as well, now using 4.6.2. I never encountered any problems with the ui directories and just use the official celestia.pro files.

As a further test, I would rather suggest to switch in qmake to the - spec win32-msvc2008 option + Qt libs compiled with VC++ 2008, in case the VC++ 2008 express compiler is installed as well on Christian's machine. Running qmake this way and compiling with the VC++ compiler should give an independent clue whether there is perhaps an incompatiility in some defaults in case of the MinGW compiler.

I noticed in NOKIA's download page http://qt.nokia.com/downloads the little star behind the
SDK for Windows link, saying at the page bottom:

*Based on MinGW (download sources) tool set. Does not support VS compiler.

Instead I always download the appropriate Qt Framework rather than the complete SDK.
For the VS 2008 compiler it is here
"Qt libraries 4.6.3 for Windows (VS 2008, 194 MB)",
http://qt.nokia.com/downloads/windows-cpp-vs2008

Last not least, if we encourage the use of the MinGW compiler more generally, it could create further problems in the future, since e.g. there is no easy transcript from our official (proven) VC++ optimization commands to an equivalent optimization in MinGW. Also there might be incompatibilities as to various libraries for Celestia that were compiled with VC++.

Fridger

[chris]

Chris, Christian,

I have built the Qt version many times both in Win32 and Linux on different machines, since Celestia-Qt exists. I have many times upgraded the Qt versions as well, now using 4.6.2. I never encountered any problems with the ui directories and just use the official celestia.pro files.

As a further test, I would rather suggest to switch in qmake to the - spec win32-msvc2008 option + Qt libs compiled with VC++ 2008, in case the VC++ 2008 express compiler is installed as well on Christian's machine. Running qmake this way and compiling with the VC++ compiler should give an independent clue whether there is perhaps an incompatiility in some defaults in case of the MinGW compiler.

I don't think that it's the compiler. It seems more likely to me that it's the new version of QtCreator that's at fault: the version of Qt that Christian is running comes with QtCreator 2.0, while previous versions shipped with QtCreator 1.3. The screenshots show that this version of QtCreator is doing a build outside of the source tree. That's a good thing in general, and I want to be sure that the Celestia code compiles correctly with that configuration. Based on Christian's experience and a look at the compiler command line from his build, Celestia is not currently set up to find the generated ui files if they aren't generated within the Celestia source tree. Fixing the problem should be a simple matter of removing the "ui/" prefix from the #includes.

I noticed in NOKIA's download page http://qt.nokia.com/downloads the little star behind the
SDK for Windows link, saying at the page bottom:

*Based on MinGW (download sources) tool set. Does not support VS compiler.

Instead I always download the appropriate Qt Framework rather than the complete SDK.
For the VS 2008 compiler it is here
"Qt libraries 4.6.3 for Windows (VS 2008, 194 MB)",
http://qt.nokia.com/downloads/windows-cpp-vs2008

Last not least, if we encourage the use of the MinGW compiler more generally, it could create further problems in the future, since e.g. there is no easy transcript from our official (proven) VC++ optimization commands to an equivalent optimization in MinGW. Also there might be incompatibilities as to various libraries for Celestia that were compiled with VC++.

I am not proposoing that we should all switch to using MinGW. I think that there's a bug in the Celestia code, I want to get to the bottom of it, and switching to a different compiler may simply mask the problem. Also, it would be a good thing if Celestia could be built cleanly with the Qt/MinGW, as it's simpler to install that then both Qt/VC++ and VC++ 2008. I suspect that the MS compiler still generates better code, though a comparison would be worthwhile now that MinGW has finally upgraded to g++ 4.x. Library incompatibilities will likely keep linking from working with MinGW though. I'm downloading the latest Qt/MinGW package now, so I'll know soon enough...

--Chris

[t00fri]

As a quick and easy further check, I just updated my Qt 4.6.2 version to the above-mentioned latest Qt 4.6.3 version that is compiled with the VS 2008 compiler. The MinGW compiler does NOT exist on my machine.

Of course, I have a proper installation of the corresponding VS 2008 Express compiler on my Win32/SP3 machine.

1) Download and install the Qt Framework: Qt libraries 4.6.3 for Windows (VS 2008, 194 MB) at this link http://qt.nokia.com/downloads/windows-cpp-vs2008

It only takes a few minutes altogether. The file associations are automatically adapted.
The new Qt version is located at C:\Qt\4.6.3. Version 4.6.2 is still there (C:\Qt\4.6.2\) and doesn't interfere. I have updated QTDIR and PATH, of course, to the 4.6.3 version (default).

2) Load Qt Creator (1.3.1 in my case) and open the Celestia project page. Then change the Qt Version by clicking "Verwaltung" and then "Auswaehlen" of the new qmake.exe path (in my case now: C:\Qt\4.6.3\bin\qmake.exe. Then click "Anwenden" and OK. Everywhere in the profile page you now must see Qt Version 4.6.3.

3) Build the latest SVN version and enjoy! Note that I did NOT touch anything in the Celestia SVN version. The Qt compile directory is in celestia/src, where celestia.pro is located.

Good luck,
Fridger

[t00fri]

It seems more likely to me that it's the new version of QtCreator that's at fault: the version of Qt that Christian is running comes with QtCreator 2.0, while previous versions shipped with QtCreator 1.3.

OK, for completeness, I also updated my Qt Creator 1.3.1 to the current version 2.0 (with MinGW download again commented out). The only change I made from the defaults in Qt Creator is the adjustment of the Build directory to the canonical celestia\src, where celestia.pro resides.

A fresh compilation with Qt Creator 2.0 and Qt 4.6.3 proceeds without any problems and the generated version runs fine.

Fridger

PS:

Here are the first lines of compilation output from Qt Creator 2.0 that show no problems with the ui directories.
---------------------------------------------------------------------------------------
Starte: "C:/Qt/qtcreator-2.0.0/bin/jom.exe"
C:\Qt\qtcreator-2.0.0\bin\jom.exe -nologo -j 2 -f Makefile.Release
c:\Qt\4.6.3\bin\uic.exe celestia\qt\addbookmark.ui -o celestia\qt\ui\ui_addbookmark.h
c:\Qt\4.6.3\bin\uic.exe celestia\qt\newbookmarkfolder.ui -o celestia\qt\ui\ui_newbookmarkfolder.h
c:\Qt\4.6.3\bin\uic.exe celestia\qt\organizebookmarks.ui -o celestia\qt\ui\ui_organizebookmarks.h
c:\Qt\4.6.3\bin\uic.exe celestia\qt\preferences.ui -o celestia\qt\ui\ui_preferences.h
------------------------------------------------------------------------------------------------------------------

PPS: Chris, your new stars also work fine in this Qt version.

[chris]

It seems more likely to me that it's the new version of QtCreator that's at fault: the version of Qt that Christian is running comes with QtCreator 2.0, while previous versions shipped with QtCreator 1.3.

OK, for completeness, I also updated my Qt Creator 1.3.1 to the current version 2.0 (with MinGW download again commented out). The only change I made from the defaults in Qt Creator is the adjustment of the Build directory to the canonical celestia\src, where celestia.pro resides.

A fresh compilation with Qt Creator 2.0 and Qt 4.6.3 proceeds without any problems and the generated version runs fine.

I installed a copy of the Qt SDK for Windows, with Qt 4.6.3 and Qt Creator 2.0. Here's what I found out:

* Linking doesn't work because of library incompatibilities. Until those are addressed, MSVC 2008 is required.
* Compiling (but not linking) worked the first time I tried it, but...
* ...that was only because I had leftover ui_ headers from building with an older SDK. After removing them, the build failed with the same errors reported by Christian.
* Removing the ui/ from the #includes in qtbookmark.h fixed compilation
* I also had a problem with the icon file not being found; stripping the path in celestia.rc fixed this.

Fridger, could you check and see if there are old ui_ headers from a previous build? It wouldn't surprise me if the MSVC build fails when these are removed.

--Chris

[t00fri]

A fresh compilation with Qt Creator 2.0 and Qt 4.6.3 proceeds without any problems and the generated version runs fine.

I installed a copy of the Qt SDK for Windows, with Qt 4.6.3 and Qt Creator 2.0. Here's what I found out:

* Linking doesn't work because of library incompatibilities. Until those are addressed, MSVC 2008 is required.

As I anticipated above. Repeated painful compatibility issues of MSVC and MinGW libs made me ban MinGW quite a while ago from my system. I know there are means to enhance lib-compatibility, but personally, I see little rationale for it in the Celestia context, since for Win-Celestia we have already committed ourselves to the (free) MSVC (Express), which is perfectly supported by the Qt-Framework.

* Compiling (but not linking) worked the first time I tried it, but...
* ...that was only because I had leftover ui_ headers from building with an older SDK. After removing them, the build failed with the same errors reported by Christian.

Fridger, could you check and see if there are old ui_ headers from a previous build? It wouldn't surprise me if the MSVC build fails when these are removed.

I wrote already above that I used a fresh Celestia.SVN checkout (rev. 5043). Already yesterday, I deleted the ui_headers and retried, just to be sure. 10 mins ago, I redid the same procedure with no ui-related problems arising as well.

But I need to emphasize once more:

The Qt compile directory is in celestia/src, where celestia.pro is located.

it all requires to set the build directory to our traditional one i.e. celestia/src, rather than using the new 2.0 default celestia/celestia-build-desktop

My QtCreator 2.0 profile page with proper <celestia>\src build directory set!

If instead I change the build directory to celestia/celestia-build-desktop, then I do reproduce Christian's file not found error in #includes of qtbookmark.h. But this is no surprise, if one modifies the built directory relative to which some other directories are referenced!

Hence I restate that using our traditional build directory celestia/src instead of the new default in QtCreator 2.0, everything works fine!

Thus my question to Christian: Did you properly set the Celestia build directory to celestia/src??
The correct build directory was also displayed in the QtCreator 1.3.1 profile page that I posted above for comparison purposes.

* I also had a problem with the icon file not being found; stripping the path in celestia.rc fixed this.

Not me with the proper celestia/src build directory set.

Fridger

[Guckytos]

First of all thanks to both of you, Chris and Fridger.

Your discussion makes a lot of things about Qt and the differences SDK <-> Framework only clearer to me. Hope it will also help others. I mean, for Linux and Windows there are descriptions in the Wikibook, what software-pacakges you need to be able to compile Celestia.
For Qt such is thing is still missing at the moment. So this here heps a lot to see things clearer.

I will try Fridger's way of using the only the Framework probably only next weekend, when I have time to reorganize my VM's (I really start to like these. Just use a basic machine and clone it to have the same base for comparison). Or trying to install the SDK with MingW disabled.

Okay now back to the compiling problem. Chris' idea about changing "qtbookmarks.h" helped the build along. Now it comes to a stop when trying to open "celestia\qt\Celestia.ico". Just to be sure I got a new version from SVN and named that "trunk 2" before changing the file and start the build. The rest of the system was untouched.

See attached screenshoot of folders and Qt log.

newbuild.png

Qt report file (qtbookmarks.h changed).txt.zip

Regards,

Christian

[chris]

Okay now back to the compiling problem. Chris' idea about changing "qtbookmarks.h" helped the build along. Now it comes to a stop when trying to open "celestia\qt\Celestia.ico". Just to be sure I got a new version from SVN and named that "trunk 2" before changing the file and start the build. The rest of the system was untouched.

Try removing the path from the icon in celestia.rc. It should contain simply the following line:

Code: Select all

IDI_ICON1 ICON DISCARDABLE "Celestia.ico"


You'll still end up with linking errors because the libraries aren't compatible with the MinGW compiler, so you'll need to install MSVC2008 as Fridger recommended. But, I'm fairly sure that you'll need these celestia.rc and qtbookmarks.h changes in order to do a clean build with the latest Qt Creator and MSVC. I'm going to try that out today.

--Chris

[t00fri]

But, I'm fairly sure that you'll need these celestia.rc and qtbookmarks.h changes in order to do a clean build with the latest Qt Creator and MSVC. I'm going to try that out today.

--Chris

So do you think I am getting dirty builds with QtCreator 2.0 and SVN 5043 ?
Please don't forget to set the build directory properly.

Fridger

[chris]

But, I'm fairly sure that you'll need these celestia.rc and qtbookmarks.h changes in order to do a clean build with the latest Qt Creator and MSVC. I'm going to try that out today.

--Chris

So do you think I am getting dirty builds with QtCreator 2.0 and SVN 5043 ?

Yes

Please don't forget to set the build directory properly.

...but perhaps not if you set the build directory to be the same as it was with older versions of Qt Creator. Anyhow, here's what I think has happened:

* Qt builds worked fine with old versions of Qt Creator
* New versions of Qt Creator use a different default build directory (outside the source tree, which is preferable)
* Celestia doesn't build correctly with the new default build directory because of easily correctable problems in qtbookmarks.h and celestia/qt/celestia.rc

It seems like the right thing to do is commit the fixes. Setting the build directory shouldn't be a required step, especially since the default out of source build is much better than having the compiler and other tools spew generated files all over the source tree.

--Chris

[t00fri]

Did you also take into consideration e.g. Linux under gcc with your fixes and that with QtCreator and without? What about Linux installations using older versions of QtCreator? If you do the compilation via qmake ... && make (i.e without IDE), there is no alternative to using a definite build directory . If the latter matches the relative directory syntax in celestia.pro and various includes, things will work, otherwise not. So far things worked fine without your fixes in every OS with the build directory properly specified. You suggest to modify Celestia's code to sync with the default build directory of a particular IDE.

I disagree that compilations should always be doable without specifying a proper build directory. If some IDE's allow to do this, it's still a limited perspective on more general terms. It might mainly be a concession to unexperienced users.

Fridger

[chris]

Did you also take into consideration e.g. Linux under gcc with your fixes and that with QtCreator and without? What about Linux installations using older versions of QtCreator? If you do the compilation via qmake ... && make (i.e without IDE), there is no alternative to using a definite build directory . If the latter matches the relative directory syntax in celestia.pro and various includes, things will work, otherwise not. So far things worked fine without your fixes in every OS with the build directory properly specified.

I haven't tried Linux. But, I have done experiments on the Mac:
* The build fails with Qt Creator 2.0 with the same error as reported by Christian
* Modifying qtbookmarks.h fixes the problem
* With qmake, I can create an Xcode project (i.e. I'm building without Qt Creator) that builds successfully with the modified qtbookmarks.h. Both qmake 4.5 and 4.6 work.
* Every version of qmake that I've tried on Mac and Windows adds "celestia/qt/ui" to the header search path. Obviously, the ui/ prefix is unnecessary. (Furthermore, the Qt example applications that use forms don't include the ui/ prefix.)

You suggest to modify Celestia's code to sync with the default build directory of a particular IDE.

I disagree that compilations should always be doable without specifying a proper build directory. If some IDE's allow to do this, it's still a limited perspective on more general terms. It might mainly be a concession to unexperienced users.

It's not just that my fix eliminates an extra step to building: the new default build directory is better. Keeping generated files separate from files under version control is a good thing, but without making small changes to two files in the current code base--celestia.rc and qtbookmarks.h--out of source builds won't work.

--Chris