I have qmake .pro file with dependency from webkit (QT += webkit). When qmake is executed and Makefile is generated, I see that it's linking to some additional libs, which was not connected explicitly in .pro file.
I would like to use newer version of some lib, and remove linkage to older version.
I have tried te following things:
Delete the Makefile
Add "LIBS -= -llibrary_name" in the end of .pro file
Generate Makefile with qmake but it does not work - linkage to older
version of lib is still present in Makefile.
Is it possible to remove linkage in current case?
You'd need to recompile your version of Qt to use the libraries you want. The information comes from the build configuration of the Qt version that you're using. Simply point Qt's configure to the relevant libraries you wish to override, build it, and use it to build your project. It will automatically pull in the newer libraries that you overrode.
Related
I have application which uses QFtp class.I have made in Qt 4 version.
But now i want to complie QFtp classe in Qt5 but it's showing some error like:
'QFtp' doesn't name and type.
how to resolve this issue. I don't want to use QNetworkAccessManager. is there any way to this?
Thank you
For the sake of completeness, the steps to use the add-ons are:
Download the sources for the add-on from https://github.com/qt/qtftp
Extract the sources somewhere (e.g. Qt5.x.y/Src/qtmyaddon)
Open a console in that folder
Read readme.txt and run the appropriate commands with the latest QT version
Run qmake
Run make (or nmake or mingw32-make or whatever)
Run sudo make install (nmake install, mingw32-make install, ...)
In the .pro file of your project, add "QT += myaddon" (e.g. "QT += ftp")
Run qmake on your project
Compile your project
I'm searching for a way to force a specific version of QT in a .pro file. To be more specific, I'd like to force qmake to use only QT 5.x version with my project instead of QT 4.x and QT 5.x
Is there a way to do so?
PS: I'm not asking for a way to stop/halt the compile process (aka check QT version, and if lower than 5.x just throw qFatal/equivalent). I'm looking for a way to actually choose which version to use while generating the Makefile with qmake
You can throw a error if a user is running qmake with a version you do not want him to use. ex:
lessThan(QT_MAJOR_VERSION, 5): error("requires Qt 5")
I really doubt you can do this. qmake is a part of framework and goes together with libraries. When you say Qt of specific verion you mean only libraries, but it is not correct.
To use specific version of Qt, you actially need to run different version of qmake. If you are using QtCreator - you should select it in project's options, if not - type absolute path to file qmake. You can find out, which version of Qt qmake uses, you can type qmake --version.
As Amartel wrote in his answer, you should point to the correct qmake version (check it by typing qmake --version in the console)
It might be that your project has been generated using the wrong qmake executable and some files are not removed even if you issue a nmake clean or make clean.
Check that there are no Makefile in the source tree after the clean (these files will typically contain the path to the qt version to use, and if not regenerated correctly will point to the wrong Qt version).
I want to build some KDE applications. Here's what I did so far:
sudo apt-get install kde-full
add LIBS += -lkdeui in the .pro file of a project which used KDE libraries.
I am using the QtCreator and the above mentioned steps don't seem to be enough. Error message: KApplication: no such file or directory.
What are the steps to configure my system for KDE application development?
The recommended way to build a KDE project is use CMake, not QMake. I really recommend you this approach because some KDE applications, like plasmoids, can not be build correctly using QMake.
In addition you can use KDevelop, but if you prefer Qt Creator, you can use it with a CMake project without problems.
http://techbase.kde.org/Development/Tutorials/CMake
KApplication.h is typically located in /usr/include/KDE folder. Make sure you have it in your include path (i.e. INCLUDEPATH += /usr/include/KDE).
I've been working on a project using OpenCV for a while, and am ready to upgrade my user interface from using cvWaitKey() to get key presses and emulating buttons with trackbars. Ha. So I've decided to use Qt.
I'd like to continue developing in the same directory I've been using, which is, of course, outside of the Qt install directory, C:\Qt\2010.05\qt. Using the "Qt Command Prompt", I'm able to compile the Hello Notepad example in directories both in and out of C:\Qt\2010.05\qt, namely C:\Qt\2010.05\qt\abc and C:\Qt\2010.05\abc.
However, while compiling under C:\ ... \qt produces executables in both the debug and release directories, compiling outside of it only produces the debug executable, along with a .o file (object code?). I did some comparisons using WinMerge, and found that the following lines (among others) differ in the two makefiles (generated using qmake -project and then qmake):
Inside qt\
first: all
install: debug-install release-install
uninstall: debug-uninstall release-uninstall
Outside qt\
first: debug
install: debug-install
uninstall: debug-uninstall
That's clearly the problem (the .pro files generated by qmake -project differ only in timestamp). I'm sure there's an easy answer out there to what's causing this... I hope there's an easy answer to how I can work around it. Also, I intend to use QtCreator some; hopefully the solution is the same for the IDE as the Command-Line compiler.
Thanks!
Nolan
p.s.: I don't think this is the same issue: Qmake does not support build directories below the source directory ...in any case, I'm not sure I understand the answer.
You should be able to add
CONFIG += release
to your .pro file, to build for release target. There's also
CONFIG += debug_and_release
iirc.
QtCreator has a GUI element for toggling between build targets, you might try opening the .pro with that application if you find you need to switch back and forth often.
I am new to qmake and I am trying to build an existing application. Qt was originally installed in /usr/local/lib/Qt-4.3.5 and 'qmake -query QT_INSTALL_PREFIX' returns that path.
I have moved the Qt library to another location and the generated Makefiles are peppered with the /usr/local original path.
How can I force qmake to use the new location I selected without recompiling Qt?
I was looking into this and found a way that works (in qt 4.7.2) by customizing qt with a qt.conf file.
In my case, I added a qt4-4.7.2/bin/qt.conf (It must be in the same place as the qmake executable)
With the following contents:
[Paths]
Prefix = c:/my_path/to/qt4-4.7.2
and the qmake -query started returning the proper paths!
See: http://doc.qt.io/qt-4.8/qt-conf.html for more details
[Update:] Since at least Qt 5.3.1 (tested with static versions of 5.3.1 and 5.5 on Windows 8) you can simply do
[Paths]
Prefix = ..
and deploy the Qt installation anywhere.
This is a 'builtin' compiled into qmake from qconfig.cpp. The best way is to reconfigure Qt with another -prefix and rebuild unfortunately. For most other variables, you can use a .qmake.cache file. See
http://doc.qt.digia.com/qt/qmake-environment-reference.html
for more info
As pointed out by Henrik Hartz, QT_INSTALL_PREFIX is built-in and can't be changed. However, if you just want to work around having to rebuild Qt temporarily, then you can try the following:
Query qmake for it's install prefix, recreate the reported directory structure, and use a symlink or hardlink to where the relocated Qt version is. E.g. on Linux
Get the path reported by /new/Qt/location/bin/qmake -query QT_INSTALL_PREFIX. Say this reports /Parent/Dirs/Prefix.
Create any parent directories of the path, e.g. mkdir -p /Parent/Dirs/
Symlink to new location, e.g. ln -s /new/Qt/location /Parent/Dirs/Prefix
The above can be also useful if you have a bunch of developers who need to work with the same prebuilt version of Qt, where this Qt version isn't necessarily copied to the same path on all the developers' computers, and where you only need to bundle the Qt shared libs with you application for end users (i.e. you won't be shipping headers or build tools).