[Moved] Auto completion in Qtcreator with multiple builds
-
Hi! I have many Qt builds for cross platform and cross architecture compilation. I noticed something very very bothering: when I select my desired Qt build for compilation, I have Qtcreator check syntax, and immediately it underlines Qt headers as header file not found and I suddenly loose the autocompletion. Autocompletion only works for my Linux build, installing using apt-get in Ubuntu.
I thought I may have done something wrong in my spacification qmake.conf, but I see no mistake. The variable QMAKE_INCDIR_QT is set according to common/linux.conf correctly to the install path. Indeed the code compiles and link correctly. It is only in Qtcreator that I experience the problem.
Any idea what the problem may be or how to figure it out? Thanks!
-
I guess you have the cross compiler environment inside one directory that mimics (to a certain degree) the environment on the device you are targeting. We call that environment "systemroot" (or sysroot) in Qt Creator.
My guess is that Qt Creator did not pick up this sysroot and is thus using "/device/path" instead of "$sysroot/device/path" to pick up include files. This does work for maemo/meego devices, but our generic cross-compiler support is not yet as strong. There might be a issue in actually being able to set up the sysroot for a Qt version that is not recognized as a cross-compiler one.
The good news is that we want to work on generic linux-based device support for the 2.3 version, so this is a really good time to raise a "bug report":http://bugreports.qt.nokia.com/ and help us figure out what goes wrong here in your use case.
A good place to start debugging is src/plugins/qt4projectmanager/qtversionmanager and there the addToEnvironment methods in QtVersion that actually set the include pathes our code model uses. The sysroot set in the relevant QtVersion would be nice to know, too.
-
Thanks for the information.
Before I go on, I would like to make sure I didn't do anything stupid. I've never set my sysroot in any way. Should I?
I don't know how Qt autocompletion works, but why should Qtcreator know where the sysroot is?
I see that Qtcreator does not find Qt headers. I get a file not found in something like:#include <QObject>
for instance. The lack of autocompletion is a consequence, I suppose...
But, in this case, is it useful to know where the sysroot is?I thought that the important thing was for Qtcreator to know where to find Qt headers, and I suppose this is the QMAKE_INCDIR_QT variable. I placed a message in my .pro file and the path is correct:
/usr/local/Trolltech/QtEmbedded-4.7.2/include
For other inclusions for the sysroot I tought it was necessary to set correctly the QMAKE_INCDIR variabile (and QMAKE_LIBDIR etc...).
Am I wrong? Am I missing any other important steps?
Thanks for your help! -
I actually think you have no sysroot set up -- mostly since we do that automatically for maemo/meego/symbian but have no UI to do so for other cross-compiler setups;-)
Depending on how you set up your cross-compiler environment you may or may not need a sysroot. The usual approach is to have a directory with everything that is on the device plus everything needed to build (headers, etc. which usually are not installed on the device, nobody is ever building there anyway, so why waste the space?). In such a setup the include pathes, linker pathes etc. are often given relative to the directory that corresponds to the root directory of the device. So the build system needs to prepend the path to that place (== the sysroot) before all directories. We do that in a couple of places to work e.g. with the symbian SDK.
You do not seem to use this approach though, considering that you put Qt into /usr/local/Trolltech:) Working with 3rd party libraries is usually a bit more tricky in such a setup, but Creator should be fine to put up the headers and libraries wherever @qmake -query@ points it to.
Please check the output of that (most easily done by hovering over a Qt version in Tools->Options->Qt4 inside Creator). Are the directories listed there correct?
-
Yes, I do have a sysroot. I placed there system libraries I have on my device, but I left out some others, like Qt.
The directories in the tools are correct. These are the output for the qmake of my system (the desktop version installed by Ubuntu):
QT_INSTALL_PREFIX:/usr
QT_INSTALL_DATA:/usr/share/qt4
QT_INSTALL_DOCS:/usr/share/qt4/doc
QT_INSTALL_HEADERS:/usr/include/qt4
QT_INSTALL_LIBS:/usr/lib
QT_INSTALL_BINS:/usr/bin
QT_INSTALL_PLUGINS:/usr/lib/qt4/plugins
QT_INSTALL_IMPORTS:/usr/lib/qt4/imports
QT_INSTALL_TRANSLATIONS:/usr/share/qt4/translations
QT_INSTALL_CONFIGURATION:/etc/xdg
QT_INSTALL_EXAMPLES:/usr/lib/qt4/examples
QT_INSTALL_DEMOS:/usr/lib/qt4/demos
QMAKE_MKSPECS:/usr/share/qt4/mkspecs
QMAKE_VERSION:2.01a
QT_VERSION:4.7.2and the qmake of one of my other builds for Qt/Embedded:
QT_INSTALL_PREFIX:/usr/local/Trolltech/QtEmbedded-rock-4.7.2
QT_INSTALL_DATA:/usr/local/Trolltech/QtEmbedded-rock-4.7.2
QT_INSTALL_DOCS:/usr/local/Trolltech/QtEmbedded-rock-4.7.2/doc
QT_INSTALL_HEADERS:/usr/local/Trolltech/QtEmbedded-rock-4.7.2/include
QT_INSTALL_LIBS:/usr/local/Trolltech/QtEmbedded-rock-4.7.2/lib
QT_INSTALL_BINS:/usr/local/Trolltech/QtEmbedded-rock-4.7.2/bin
QT_INSTALL_PLUGINS:/usr/local/Trolltech/QtEmbedded-rock-4.7.2/plugins
QT_INSTALL_IMPORTS:/usr/local/Trolltech/QtEmbedded-rock-4.7.2/imports
QT_INSTALL_TRANSLATIONS:/usr/local/Trolltech/QtEmbedded-rock-4.7.2/translations
QT_INSTALL_CONFIGURATION:/etc/xdg
QT_INSTALL_EXAMPLES:/usr/local/Trolltech/QtEmbedded-rock-4.7.2/examples
QT_INSTALL_DEMOS:/usr/local/Trolltech/QtEmbedded-rock-4.7.2/demos
QMAKE_MKSPECS:/usr/local/Trolltech/QtEmbedded-rock-4.7.2/mkspecs
QMAKE_VERSION:2.01a
QT_VERSION:4.7.2The directories seem correct, the Qt headers are there. Why isn't Qt Creator aware?
-
I do not know a solution for your issue from the top of my head, so writing a bug report is a good way to get someone more knowledgeable in this area to look at your problem.
-
I reported this bug here http://bugreports.qt.nokia.com/browse/QTCREATORBUG-4812 but it seems it has already been fixed in 2.2. I hope Ubuntu will release it soon then.
Thanks!