Qt5 with VC++ 2012 and OpenGL

silicomancer

We planned to transit our Qt5 projects from VC++ 2010 to VC++2012.

I just realized there is no prepared build of Qt5/OpenGL that had been built with VC++2012 in 32Bit. Only a Qt5/OpenGL/2012/64Bit build is available and a Qt5/ANGLE/2012/32Bit build.

Is there a special reason why the Qt5/OpenGL/2012/32Bit version isn't provided?

JKSH

Hi,

See my posts at 1 October 2013 and 5 October 2013 at http://qt-project.org/forums/viewthread/24828/

silicomancer

So there are no technical reasons? Then I need to build the missing variant from source since porting our projects to 64 Bit is very low at our priority list.

BTW At some point we will add both 32 and 64 Bit targets to our projects. Can 64 and 32 variants of Qt coexist? Do we need two separate Qt installations/builds or can both exist in a single Qt folder?

tilsitt

Hi,

Because the built libraries have the same name, regardless of architecture, you will have to build the 2 version in separate folders. But there is no issue having the 2 versions coexisting on your system. You will choose which one you're compiling with in QtCreator (or in cmake depending on your tools).

silicomancer

Ok. Thank you very much for your answers!

JKSH

When you reach that stage, see these pages for info on adding your different variants to Qt Creator:

silicomancer

I just read how to build Qt 5... that isn't funny.

I checked http://qt-project.org/doc/qt-5.0/qtdoc/install-win.html and http://qt-project.org/doc/qt-5.0/qtdoc/requirements-win.html

Is it really that complicated?!

Sure, it is long time ago when I build Qt before. I think it was some Qt 4.0.x. It was totally enough to configure and make Qt and everything worked. That was ok. But now Qt requires a lot of steps and third-party installations before I can even start with configuration und making. And hopefully all the newest versions of those tools do not introduce errors into the build process or the built framework because they have not been tested together.

I understand that it is hard to provide all pre-built variants of Qt - but considering the effort and knowledge that seems to be necessary to build Qt today, it would really be a good idea to provide more pre-built packages.

Are there any sources for the builts that are not provided by Digia?
I would really like to prevent the approaching pain and loss of time.

JKSH

The only strict requirements are Perl and Python.

You don't need most of the dependencies if you're not building the Qt WebKit module (just move/delete the qtwebkit folder from your source tree). Just open your Visual Studio command prompt, configure, and run nmake.

silicomancer

Ok, I am just trying it out. Maybe you can give some more advice:

Is there an other safe way to ingore WebKit other than deleting the sources? Maybe using something like "-skip WebKit" or "-skip QtWebKit" in configure? Or is deleting the folder the better way?

Is there some special configure option I need to build Qt as the OpenGL variant? I found some ANGLE options but no OpenGL options I could supply to the configure call.

JKSH

For skipping WebKit, I believe the option is -skip qtwebkit but I've never used it myself (I build from git, and I simply didn't download the repositories that I don't use).

For OpenGL (requires version 2.0 or higher), the option is -opengl desktop.

This is what I'd do:
@
configure -opensource -confirm-license -nomake examples -nomake tests -opengl desktop -mp
nmake
nmake install
@

-mp makes nmake run on multiple cores for faster compilation

silicomancer

Thats very useful.

That -mp option is indeed very interesting since I use a 8-core CPU and an SSD. However I considered installing jom before.

Has jom any advantages over nmake with a -mp configured project?

JKSH

Not that I can think of. Jom is an nmake clone, designed specifically to add multithreaded compilation: http://blog.qt.digia.com/blog/2009/03/27/speeding-up-visual-c-qt-builds/

Recent versions of nmake have multithreading built-in, so jom's original advantage is gone.

EDIT: I just read the comments in the blog post above. It looks like nmake did support "mp" since MSVC 2005, but it was buggy back then. I've had no issues with nmake + "mp" in MSVC 2012 though, so I didn't download jom

silicomancer

Ok. An update in case someone is interested. I finally managed to build Qt5/OpenGL/2012/32Bit by try-and-error. Of course without WebKit (which probably would have driven me nuts). Thanks god I have a fast SSD and an 8-core processor.

It turned out that it is not possible to clean the configuration. Make target "confclean" is broken for two years (https://bugreports.qt-project.org/browse/QTBUG-20566). So I made a clean source copy for each try. What a pain. It is definitely NOT possible to simply call configure with new parameters. There seems to be a workaround but I could not test it anymore.

I also compared jom and nmake+mp. They both seem to work on multi-core systems. But jom utilized my 8 cores and my RAM much better than nmake+mp did. It seems to have a far better parallelization and concurrency. So I sticked to jom.

I need to say that building Qt is unnecessarily hard with so few documentation about how exactly the configuration options have to be used. How can I surely know which options are missing compared to Digias pre-built packages other than by many hours full of painful copy/configure/build/try/error?

I also added the needed SSL and MySQL support. My current configure call looks like this:
"configure -shared -confirm-license -opensource -debug-and-release -c++11 -platform win32-msvc2012 -skip qtwebkit -opengl desktop -mp -plugin-sql-mysql -I C:\MySQL\include -L C:\MySQL\lib -openssl -I C:\OpenSSL-Win32\include -L C:\OpenSSL-Win32\lib\VC"

I now have a Qt folder with a totally different structure than the Digia installations. This breaks all of our installer scripts, links and additional build batches. We could adapt to this but it would be impossible to switch our application environment between Digia-compiled and self-compiled directories on the fly. I also started the selfmade QtAssistant and it simply has no content. I didn't test our applications with that selfmade build and probably I won't. I don't have the time to clear so many problems.

There were two things I wanted to suggest to Digia: Make the docs more detailed and add more pre-built packes. Currently I want to suggest only the latter. Adding more variants to the build servers is definitely the better way to go than burden the developers with such unnecessary loss of time.

We planned to transit all of our Qt projects to VC++2012 and to x64 architecture in the next months. We intended to do this in separate steps to reduce the risk and effort. But unfortunately both packages that would allow us to do this separately are currently not provided by Digia: Qt5/OpenGL/2010/64Bit and Qt5/OpenGL/2012/32Bit both are not supported. This is pretty unfortunate.

JKSH

Thanks for sharing your solution and nmake/jom comparisons. I'm sorry to hear that you've had a frustrating experience.

If you're keen to make a suggestion to Digia, post it to https://bugreports.qt-project.org (very few Digia staff visit these forums)

[quote]I now have a Qt folder with a totally different structure than the Digia installations. This breaks all of our installer scripts, links and additional build batches.[/quote]I wasn't expecting this though. What folder structure do you now have?

silicomancer

The precompiled packages contain top level folders with maintanenance tools and stuff and separated soruces. But that wouldn't be a problem since we reference the folder named "msvc2012" (or similar).

However within that folder there is one set of common folders "bin", "doc", "examples", etc. at top level using the Digia build. The self-compiled build on the other hand contains one folder per Qt-module and each of those module folders contains a separate set of "bin", "doc", "examples", etc. folders.

This was differently when I built Qt 4.0.x ages ago. I think there were no difference between a self-built and a pre-built Qt. Which was very good.

I know the bugtracker. I reported several bugs there. However I feel that suggestions usually are ignored or never implemented (which also changed since Trolltech times, where I reported about 60 accepted suggestions and the same number of bugs).

JKSH

You can find the complete collection in C:<Qt>\qtbase, e.g.

C:<Qt>\qtbase\bin
C:<Qt>\qtbase\doc
C:<Qt>\qtbase\include

I believe you can install the files elsewhere by setting the -prefix flag during configuration, and then call jom install after compilation has finished.

The Qt Project has grown considerably under Nokia + Digia, compared to its Trolltech days. The downside is an exponential growth in incoming bug reports/suggestions. Digia staff do resolve many reports daily: https://bugreports.qt-project.org/browse/QTBUG (that's 700 new public reports, with 500 resolved, in October 2013. Not counting private/commercial reports.)