I have a project that uses Qt. So I have "qmake" make my Makefile from the .pro file. But Qmake can also make that .pro file: qmake -project . This worked until I needed to add an external extra library to my project.
I get lots of hits on google that tell me to add LIBS += ... to my project file, but I want to tell qmake -project something that causes it to add it for me. In effect of course I'll be doing it myself, but I don't think that it's proper that I am editing the generated project file.
If for example I add files to the project directory, I'll have to recreate it and add in the library again, or I'll have to manually add the files to the (almost completely computer-generated) project file. I'm now using a script to auto-generate the project file, and then add in the LIBS += directive, but is there a proper way to do this?
When you are developing without the Qt Creator IDE, unless the IDE includes by itself some automatic utilities, you must edit manually the .pro configuration file.
The generated .pro file is a skeleton file which YOU must fill in with the libraries that you need, then the qmake system figures out the other dependencies and compiles your project. It is a essentially a much better version of pkg-config of gtk + Makefiles.
When you add more source and resource files to your project then manually you must add them to the .pro file.
Example:
QT += core gui
TARGET = qtcp1
TEMPLATE = app
SOURCES += main.cpp\
mainwindow.cpp \
miwidget1.cpp \
lcdrange.cpp
HEADERS += mainwindow.h \
miwidget1.h \
lcdrange.h
FORMS += mainwindow.u
Alternately, you can issue qmake -project over and over again, but this can cause some unforseen accidents, since it includes everything that is in the current directory at the time, including the pre-processed files for conversion to standard C++ from QT dialect. This intermediate files must be erased (cleaned), before the remaking the project and the next make or can lead to tricky problems.
Using the official and free QT Creator IDE takes away most of this burden by adding automatically the new data to the .pro file and cleaning loose ends. Some other IDEs like Code::BLocks and Codelite provide some facilities for QT, but not to the level of QT creator. Some prefer to edit the .pro themselves for custom reasons, other like more other styles of IDEs, like Eclipse.
You should test the waters and decide by yourself what fits best to your needs.
ReEdited, to clarify a few things.
Related
In qmake based projects, it's possible to include OTHER_FILES to use them in QtCreator, e.g.
QT += core gui widgets
TARGET = example-program
TEMPLATE = app
HEADERS = mainwindow.h
SOURCES = main.cpp mainwindow.cpp
OTHER_FILES = README.md LICENCE examples/network/server.c
That way one can access README.md within QtCreator easily. A CMake file with the same target looks like
cmake_minimum_required(VERSION 3.5)
project(example CXX)
set(CMAKE_AUTOMOC ON)
find_package(Qt5 COMPONENTS Core Gui Widgets REQUIRED)
set(HEADERS mainwindow.h)
set(SOURCES main.cpp mainwindow.cpp)
set(OTHER_FILES README.md LICENCE examples/network/server.c)
add_executable(example-program ${SOURCES} ${HEADERS})
target_link_libraries(example-program Qt5::Core Qt5::Gui Qt5::Widgets)
However, the OTHER_FILES aren't shown in QtCreator and I have to access them via "File > Open" instead of the project browser. Is there a workaround?
You can use a custom target that depends on the given files:
add_custom_target(project-related-files SOURCES ${OTHER_FILES})
Since the COMMAND is missing, an empty target will be generated, but it will still depend on the SOURCES. This is also the official way to include other files into an IDE:
SOURCES
Specify additional source files to be included in the custom target. Specified source files will be added to IDE project files for convenience in editing even if they have no build rules.
There's no problem with adding non-compiled files as the sources of a CMake target; CMake will simply ignore them if it doesn't recognise their extension. So you can easily do this:
add_executable(example-program ${SOURCES} ${HEADERS} ${OTHER_FILES})
With files which could be confused for actual sources (based on their extension), there's always the option of setting their HEADER_FILE_ONLY property to true:
set_source_files_properties(
${OTHER_FILES}
PROPERTIES
HEADER_FILE_ONLY TRUE
)
I'll comment that I think both answers are correct, which to use depends on the particulars of the project.
Angew's answer adds the files to a single project, within the project.
In my case, Zeta's answer worked better, as I had files at the top-level of a project with subprojects, and having a new folder (with a name I could customize) in QtCreator better fit my needs.
Adding an additional answer, as I didn't see the differences between the two approaches mentioned.
I have several Qt projects that are dependent upon a Qt library that I've developed.
The project files (.pro) for projects which use the library define the LIBS and PRE_TARGETDEPS paths. For example: -
PRE_TARGETDEPS += ../ProjectLibrary_Qt_5_2_1_clang_64bit-Debug/projectlibrary.dylib
LIBS += -L../ProjectLibrary_Qt_5_2_1_clang_64bit-Debug -lProjectLibrary
As you can see, there is a defined path to the linked library and they have been building with Shadow Builds, via Qt Creator. The file hierarchy is like this: -
Projects
ProjectLibrary_Qt_5_2_1_clang_64bit-Debug
ProjectLib.dylib (the built library)
DependentProject
DependentProject.pro
(dylib is an OSX extension, but it could equally be .lib for Windows, or .so for linux)
However, Jenkins creates a different folder structure:-
jobs
ProjectLib
workspace
Project.dylib
DependentProject
workspace
DependentProject.pro
Now there is an extra directory (workspace), which would need this reflected in the .pro file and the names of the folders are different.
Obviously, If I just call qmake on the .pro with a Jenkins build, the path to the library is going to be wrong.
So, do I need to create a separate .pro just to be able to reflect the paths when building with Jenkins, or is there another way to handle specifying the location of libraries in the project file, for Jenkins, without having to change the directory structures?
Solution 1) Based on your current build configration
Modify your .pro file like this :
isEmpty(PROJECT_PATH) {
PROJECT_PATH=../ProjectLibrary_Qt_5_2_1_clang_64bit-Debug
}
LIBS += -L$${PROJECT_PATH} -lProjectLibrary
Then in Jenkins , you should pass PROJECT_PATH={path to your project} to qmake
Solution 2)
Using git submodule to fetch ProjectLibrary as a part of your building project. Then you don't need to build the ProjectLibrary by Qt Creator manually.
I am using Qt Creator to rewrite my former project which is developed in Visual Studio. In this project I need to use an external library (gloox for xmpp).
Here's what I did in Visual Studio:
Add c:/dir1/ to the Additional Include Directories, that's where the tons of .h and .cpp files are.
Add c:/dir2/ in the linker setting, that's where the .lib file is.
I want to do the same thing in Qt Creator, so I added INCLUDEPATH += c:/dir1/ to the end of my .pro file, but when I qmaked again I still could not include anything from dir1 successfully.
#include <message.h>
C1083: Cannot open include file: 'message.h': No such file or directory
What should I do?
Based on the comment discussion, the problem seems to be that, after the INCLUDEPATH and potentially other relevant modifications, you forgot to properly re-run qmake.
This is necessary when dealing with QtCreator unfortunately due to the following long-standing issue:
Creator should know when to rerun qmake
I found the solution: copy everything in the .pro file and delete the .pro file. Then create a new .pro file and copy everything back, then execute qmake then run.
I compiled a library using the MinGW toolchain provided with Qt 5.0.2 on Windows. As a result I received a library.so file. First I failed using the library in a Qt application, but now I found out that everything works fine when I make a copy of the liblibrary.so file and call it liblibrary.dll or liblibrary.lib (which is the only file ending supported by the add library wizard in QtCreator).
Now I wonder if this is normal or if I should change something in order not to have both files (which are exact copies). Leaving one away makes the application crash during start up. I added the library as follows to my Qt pro file:
LIBS += -L"../path/to/library" -llibrary
INCLUDEPATH += $$quote(../path/to/library)
EDIT: I compiled the library using the MinGW of Qt, not as Qt project but using mingw32-make and the provided Makefile. As a result I get the liblibrary.so.
EDIT: It seems to work also when renaming the copy to liblibrary.dll instead of .lib. But still, I need two files to make the application work -- the .so and the .dll.
Chris
That's weird, I think you should get a *.a and *.dll files when building a shared lib with MinGW on Windows, as said in the documentation:
In windows, MinGW will output .a and .dll, MSVC2010 will ouput .lib and .dll. In linux, MinGW will output .so, .so.1, .so.1.0 and .so.1.0.0 – .lib, .a and .so are import libraries.
You definitely shouldn't rename your file!
Be careful to:
not to include the "lib" prefix after "-l" in your project file.
put everything after after "-l" in lower case as you're on Windows
not adding any extension to your library name after "-l"
add and reference the .h file used in your library
A real example using QtWebsocket lib:
INCLUDEPATH += "$${PWD}/include/"
LIBS += -L"$${PWD}/libs/" -lqtwebsocket
...
HEADERS += ... \
$${PWD}/include/QWsSocket.h \
...
In my include/ folder, I have the following file:
QWsSocket.h (taken from original project - required)
In my libs/ folder, I have the following file:
libQtWebsocket.a
QtWebsocket.dll
Edit: I struggled with this too initially. Have you tried to build your lib as a static lib instead (CONFIG += staticlib in your library project)? This might help you getting you *.pro file right before switching to using the shared library.
Edit 2: Ok, the fact that you get a *.so file is still a bit odd. In this question
the user has the same issue as you and keep both files, which is just a workaround. According to a later answer it seems that you need to modify your makefile to generate a file with the proper extension. Maybe this will help: http://www.mingw.org/wiki/sampleDLL
I want to build qt application that will gather all the necessary binaries for standalone execution on install.
I know that can be done in lines of:
QT_DIR=C:/Qt/4.8.4
dlls_to_move.files += $$DIR/bin/QtCore.dll
however that seems clumsy. Is there a way to retrieve Qt binary folder actually used, like project directory that can be retrieved with $$PWD?
From qmake Advanced Usage:
The special $$[...] operator can be used to access various configuration options that were set when Qt was built:
So I think you'd want to do this in your project file:
dlls_to_move.files += $$[QT_INSTALL_BINS]/QtCore.dll