Hi, I took the liberty to link to this thread from the wiki page :) I'd like to suggest a couple of changes, but on the other side do not want to start an edit war ...

Don't advocate the use of "./qtrepotools/bin/qt5_tool -p" . It'll check out the master branches of every repo, which more likely than not break compilation . People who really want to live on the bleeding edge will find out how to achieve that ... There should be no further steps necessary (no git remote rm gerrit, no special webkit/v8 handling). It's IMO a high priority bug if that doesn't succeed, so don't advocate workarounds!

Along the same line, a way to update Qt5 repo isn't qt5_tool -p, but git pull && git submodule update --recursive!

Hi! Please feel free to edit the wiki article as to the latest recommendations. I put the basic instructions up a while ago now so I am not surprised if much has changed. The usage of qt5_tool -p came from a troll on #qt-labs at the time.

A quick question, if we should not use qt5_tool -p then why does it exist?

Others have added the gerrit-related stuff and other bits and pieces.

Could you add a brief not on how to live on the bleeding edge then please? This is supposed to be an article to help people do so so that they can contribute back under Open Governance.

Okay. The thing is that now Qt is modularized, every module moves at it's own speed, but there are of course dependencies. E.g. a recent change in qtbase might break qtdeclarative and so on ... There's no way we can ensure that all master branches at a time work with each other (also due to the CI system). Therefore the qt5.git repo contains a list of 'known' SHA's from every module that are known to work together. It's of course not bleeding edge, but a good baseline to start with.

On mac 10.6.8, I have problems building this. The linker complains about an nonexistent "OpenGl" library. After replacing with "OpenGL" (notice capital L) in the offending files* this issue resolves.
Unfortunately QtQuick2.0 examples don't work. For some reason importing folders from QML files is not working as it should. qmlscene doesnt recognize the imported folders (despite the fact that they are there at the same level as the invoking qml file). I keep getting:

@jmfairlie: I'm not working on Mac OS X, sorry. You should raise your problems (after verifying that the problem is still there in latest master branch of e.g. qtbase) on IRC/freenode, #qt-labs channel . Or you raise it on qt5-feedback@qt.nokia.com .

Now I tried with Ubuntu 11.04 with an ATI gpu (might be relevant) and linker isn't able to find GL libraries. Indeed, for some reason, there is no /usr/lib/libGL.so in my machine (not sure if this is normal) but only in /usr/lib/mesa and /usr/lib/fglrx.

If I add "-opengl desktop" to configure then it shows the message:

The OpenGL functionality test failed!
You might need to modify the include and library search paths by editing
QMAKE_INCDIR_OPENGL, QMAKE_LIBDIR_OPENGL and QMAKE_LIBS_OPENGL in
.../qt5/qtbase/mkspecs/linux-g++.

If I follow the suggestion and add those lines to qtbase/mkspecs/linux-g++/qmake.conf :

It doesn't make a difference and linker is still unable to find the GL libraries, (I guess those macros are not being used)

However if I just add a symlink to any of the GL libs to /usr/lib it finally finds them.

Unfortunately, QtQuick2.0 examples (what I'm interested in) don't work either, this time qmlscene SEGFAULTS in a seemingly unrelated call ... I guess I'll need to wait until a more stable version comes out.

Ubuntu 11.04 is used heavily in the development teams, so this should really work out of the box, without any environment variable tinkering. The libgl1-mesa-dev should include the /usr/lib/libGL.so file, try installing this package. (Btw, you can find out which package provides which file by using the "apt-get file search" command).

For reference, this is the output "configure -nokia-developer -nomake examples -nomake demos -nomake tests" gives me on an Ubuntu 11.04:

After compiling Qt5 I'd like to do a safe "make install" in my system. With "safe" I mean that I don't want to overwtite my Qt4 libs on my system so they should be installed in (for example) /opt/qt5 if it's possible.

I also would like to start packaging Qt5 in a Ubuntu PPA, but even if I've a little experience with packaging, I really don't know how to split an installation in multiple packages (I mean: qt-multimedia, qt-database, qt-tools ecc.... just to make you an example): should I take example from the actual Qt4 packages available in Ubuntu? Anyone want to help me? Thanks!

I get this at every dir level I tried on Archlinux x86_64...
@~qt5-git/qtbase git submodule update --init src/3rdparty/v8
You need to run this command from the toplevel of the working tree.@
I already have a libv8 3.6.5.1 as part of my system so would it possible for qtbase and whatever else needs libv8 to just link against my system version?

Hi! Trying to build Qt 5 for the first time, but I'm not getting very far...
Seems like the init-repository script is not working properly with the the --http option. All the repos are cloned using "http:", except for the qt3d repo which still tries to use "git:".
Very simple problem, but with my total lack of experience with perl, I'm not sure how to work around it... If anyone could give me a hint on how to get past this, by fixing init-repository, or doing some manual step, it would be most appreciated.

What is the best way to incorporate qtwebkit into a qt5 build?
@...
[pid 30835] open(".../qt5-git/.git/modules/qtwebkit/refs/heads/master", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30835] write(2, "fatal: Oops\n", 12fatal: Oops@

@ludde, I'm not sure why there is not some plain English instructions to clone the repo exactly, or a bash script, rather than buried inside an obfuscated perl script that doesn't seem to work. An example .git/config file would be more useful.

Had this problem too. For some reason you need not only have gcc installed, but have it available as g++. This can be accomplished by installing the g++ package (and possibly also by just creating an alias from g++ to gcc, but I didn't try this).

Strangely, i cannot run demos as even if i make the executables runnable, then i get something like this:
@Details: Failed to execute child process "/usr/bin/tea_service" (No such file or directory)@

after making the qt teaservice.desktop demo executable as a program in its right click properties and trying to run.
Somehow i get the impression that this is not what i am meant to be doimng anyway, as the idea that i would have to right click and change the permissions of all the demo files that i wanted to run doesn't seem the most fun so i guess i am trying to do it the wrong way :$

This target is using the GNU C++ compiler (linux-g++-64).
Recent versions of this compiler automatically include code for
exceptions, which increase both the size of the Qt libraries and
the amount of memory taken by your applications.
You may choose to re-run configure with the -no-exceptions
option to compile Qt without exceptions. This is completely binary
compatible, and existing applications will continue to work.

These assume they're only included from within WebKit - untrue.
Yes, I later realized that this isn't the right place to change them.
@
./qtbase/include/QtWebKit/qwebview.h
./qtbase/include/QtWebKit/qwebframe.h
./qtbase/include/QtWebKit/qwebkitversion.h
./qtbase/include/QtWebKit/qwebpluginfactory.h
./qtbase/include/QtWebKit/qwebinspector.h
./qtbase/include/QtWebKit/qwebkitplatformplugin.h
./qtbase/include/QtWebKit/qwebhistoryinterface.h
./qtbase/include/QtWebKit/qwebsecurityorigin.h
./qtbase/include/QtWebKit/qwebelement.h
./qtbase/include/QtWebKit/qwebpage.h
./qtbase/include/QtWebKit/qwebdatabase.h
./qtbase/include/QtWebKit/qwebhistory.h
./qtbase/include/QtWebKit/qwebkitglobal.h
./qtbase/include/QtWebKit/qwebsettings.h
@

I re-subscribed and posted an email with a QtWebkit patch although my build still (eventually) fails.

I think that as long as the install prefix is inside the source tree (not to mention the build path!) you're going to have problems, so I won't try it again at least until these things change.

From trying to fix problems I noticed that there are several "Release" directories created in the source tree - it looks like someone was at least trying to do some whacky kind of out-of-source-while-still-in-source deal.

Do a "find . -type d -name Release" once you've tried to build it at least once to see the strangeness.

I also noticed that the build process was picking header files from the install path in preference to the source directory - I've got projects that use automake that don't do that (it's a shame automake can't do the same for libraries).