I'm going to achieve the following hierarchy in my QtCreator project based on subdirs template:
Project:
subproject1 - static library
subproject2 - static library
subproject3 - unittests executable
The only one executable will be in subproject3, which will link against subproject1 and subproject 2.
However build works fine I've noticed some usability issue. When I run the whole project it tries to find executables in my libraries - and fails. I have to run subproject3 instead of the main one.
Is it possible to avoid such situation?
I am using a similar hierarchy for the unit-tests - and the .pro file should have the following lines in it
INCLUDEPATH += ../subproject1/ \
../subproject2/
After adding the folders in the INCLUDEPATH variable, you can add the sources and header that you need using the SOURCES and HEADERS variables.
Hope it helps you
Related
I'm trying to use a SUBDIR qmake-project with relative subdirectories:
TEMPLATE = subdirs
SUBDIRS = app ../lib1
When QT creator build this project using "shadow build", which means in an other directory, it puts the output of the file this way:
Shadow-Build-Directory/
app/
main.obj
...
The problem is that because my subdir is relative, it uses the same relative path for the output, trying to put lib1 build in Shadow-Build-Directory/../lib1 !
How can I avoid this ?
EDIT: I'm using latest Qt 5.5.
New answer : I made some tests and being outside of the root project seems to be a big problem for qmake : $$shadowed() returns nothing (as stated in the documentation for being outside of source tree), and for the same reasons, .qmake.conf (undocumented feature) in root project directory isn't loaded in lib1 project.
I think the solution to you problem is to keep lib1 as a standalone project, build the library once and for all. Then include the reference to the binaries and headers of lib1 in each of your projects.
It could even be automated with qmake features :
In each of your projects, you give the path of your lib1 properly written feature, then adding
CONFIG += lib1
would automatically configure include path and link directive for your projects.
Old Answer :
Can't try right now, but I guess that
DESTDIR = $$shadowed($$PWD)/lib1
in lib.pro file should fix you problem.
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 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 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.
I'm new to QT Creator. I want to create a QT project with an exe and a static lib.
If I create the exe project first, it builds/rebuilds fine for every build configuration.
However, when i add TEMPLATE = subdirs to the end of the .pro file it stops building correctly. But it appears that is necessary to add static libs to the project. Any idea what I may be doing wrong?
Thanks.
The idea is to have a .pro file with TEMPLATE = subdirs on the toplevel and then the executable in one subdirectory and the library in another. Add both directories to SUBDIRS.
AFAIK it is not (easily) possible with qmake to build something and also recurse in one .pro file.
I am not sure about Qt Creator support, but it is easy to create the TEMPLATE = subdirs .pro file by hand.
edit:
I'm sorry, I did not understand what you are trying to do, can you explain better?
Does this help:
The template can be overridden by specifying a new template type with the -t command line option. This overrides the template type after the .pro file has been processed. With .pro files that use the template type to determine how the project is built, it is necessary to declare TEMPLATE on the command line rather than use the -t option.
from here