I have been told that it is possible to generate a pkg-config file through qmake, but I have no idea how to do it. I have been looking online for a while, and it seems as though it is something you just have to know how to do. Can someone give me an example, or point me to some sort of guide/tutorial?
If you want to generate a .pc file (in contrast to simply use pkg-config to find dependencies, which is well supported by qmake), you might be interested in the following. Obviously, creating .pc files is a less visible, but existing feature of QMake. You want to use CONFIG += create_pc, which depends on create_prl. If you don't want to install the .prl file, use no_install_prl, too. Overall, this gives you:
CONFIG += create_pc create_prl no_install_prl
QMAKE_PKGCONFIG_NAME = VigraQt
QMAKE_PKGCONFIG_DESCRIPTION = Qt4 bindings for the VIGRA library
QMAKE_PKGCONFIG_PREFIX = $$INSTALLBASE
QMAKE_PKGCONFIG_LIBDIR = $$target.path
QMAKE_PKGCONFIG_INCDIR = $$headers.path
QMAKE_PKGCONFIG_VERSION = $$VERSION
This is what I came up with for VigraQt. There's also QMAKE_PKGCONFIG_DESTDIR, which you may use to specify the location of the .pc files within the source directory. Finally, there are QMAKE_PKGCONFIG_VARIABLES, QMAKE_PKGCONFIG_REQUIRES, and QMAKE_PKGCONFIG_CFLAGS in addition to the above.
(There is also create_libtool for .la files, which also depends on the .prl files.)
Is this what you are looking for?
To generate pkg-config using qmake you have to add to (modify) your project file (*.pro file):
unix {
CONFIG += link_pkgconfig
PKGCONFIG += <pc_file_without_extension>
}
Related
When writing plugin libraries with Qt one can attach a JSON file containing some meta data to it using the Q_PLUGIN_METADATA macro. This JSON file is then linked into the library, for later usage with QPluginLoader::metaData().
Unfortunately when building the plugin library the associated JSON file is not by default seen as a dependency for the library binary by qmake. When the JSON file is modified the plugin library project has to be rebuild (especially re-linked) manually to force the modified JSON file into the library binary.
What would be the proper way to mention the JSON file in the .pro file so that it is automatically linked in when it is modified?
I typically use the following to make the json file a dependency of the generated moc file that contains the corresponding code. Assuming the class where you specify Q_PLUGIN_METADATA is located in a header file called myclass.h, the qmake code is as follows:
DISTFILES += myclass.json
json_target.target = moc_myclass.o
json_target.depends += $$PWD/myclass.json
QMAKE_EXTRA_TARGETS += json_target
Note: You might have to use json_target.target = $$OBJECTS_DIR/moc_myclass.o instead, if OBJECTS_DIR has previously been defined. Check the generated Makefile to see if the path of the dependency matches the one of the corresponding target.
Well, you could just add the JSON file to resources: create some *.qrc file, add yours there and then write in the .pro file something like RESOURCES += plugin_data.qrc.-
There is also DISTFILES variable, but AFAIK it's Unix-only and does not solve your problem.
Tried myself and it never worked, still the recipe from documentation works: INCLUDEPATH += JSON_FILE_LOCATION_DIR. It's true that qmake caches builds sometimes, but they say adding to include path should do the trick and make a proper build.
How can I use HKDF library in my qt project? I found this library seems appropriate in qt (I checked with my source), but I couldn't include this header to project.
Adding a library to a Qt project is actually quite simple. In your qmake .pro file you need the following:
# This is the search location for the compiler to look for headers that accompany your library.
# For system libraries that typically resides under **/usr/include** or **/usr/local/include** if you used `make install`.
INCLUDEPATH+="/path/of/headers/for/library"
# This is the search location for the compiler/linker to look for the library itself.
# For system libraries this is usually somewhere under **/usr/lib** or **/usr/local/lib**
LIBS+= -L/path/of/library/itself
# This is the name of the library to include at link time
# without the **lib** prefix and the **.so** / **.a** / **.lib** / **.dll** extension.
LIBS+= -lMyLibraryName
# This is the full path of the library file itself
# *including* the aforementioned **lib** prefix and the **.so** / **.a** / **.lib** / **.dll** extension.
# This is used by qmake to look for changes to the library at build time,
# to make sure it is re-linked on change and other dependency related stuff
PRE_TARGETDEPS += /path/and/filename/of/library/itself/libMyLibraryName.lib
TIP: All the paths, unless they are specified as absolute paths (starting with '/') will be relative to the build directory. This might be the project directory, but in the case of shadow builds, it will be the shadow build directory. As a tip, simply prepend the following to your relative paths to make them relative to project directory: $$_PRO_FILE_PWD_/ so if for example your lib resides in /my/qt/project/libs/mylib you could make your project resilient to moving by using $$_PRO_FILE_PWD_/libs/mylib instead. Please note that the "project dir" is the location of the qmake .pro file.
I use CryptoPP HKDF implementation by https://www.cryptopp.com
Firstly, build static lib for valid architecture and for your platform (MacOS, Android, iOS, etc). CryptoPP Wiki has working manuals and scripts.
Then, just add 2 lines to your qmake *.pro file:
INCLUDEPATH += $$DEV_LIBS_PATH/cryptopp/$$ANDROID_ARCH/include
LIBS += -L$$DEV_LIBS_PATH/cryptopp/$$ANDROID_ARCH/lib -lcryptopp
as you can understand, I used qmake variables DEV_LIBS_PATH and ANDROID_ARCH which are just compose right path to relevant headers and static library libcryptopp.a.
I'm new to Qt, and got following error to my C++ project:
fatal error: apr_pools.h: No such file or directory
I installed apr from https://apr.apache.org/compiling_unix.html and compiled it by executing:
./configure
make
make install
But I have no idea now how to link proper files to my project.
I solved my problem by adding external library. The result in .pro file is as below:
unix:!macx: LIBS += -L/usr/local/apr/lib/ -lapr-1
INCLUDEPATH += /usr/local/apr/include/apr-1
DEPENDPATH += /usr/local/apr/include/apr-1
But anyway thanks everyone for their time and good intentions :)
You must:
Specity in your .pro where header files must be searched: something like win32:INCLUDEPATH += "C:/mylibs/extra headers"
unix:INCLUDEPATH += "/home/user/extra headers"
You must specify which library must to be linked: something like
win32:LIBS += /mylibs/lib.so
unix:LIBS += c:/mylibs/library
This is not about linking but about preprocessing for now. (the preprocessor = the program or part of the compiler which read all the lines beginning with a '#' and replace macro and insert included headers.)
The preprocessor can't find your header
see http://qt-project.org/doc/qt-5/qmake-project-files.html#declaring-other-libraries
you have to add an include path to where your additional headers are.
[EDIT]
But there are no packages in your distribution ?
What is you OS, or linux distribution ?
if you want to install the bins and headers, maybe something like ./configure --prefix=/usr ; sudo make install should be needed or copy the files directly (adapt to your system and for the makefile)
[/EDIT]
Let's say I have a Qt application where I have two classes with the same name in two different namespaces:
namespace namespace1
{
class SomeClass;
}
namespace namespace2
{
class SomeClass;
}
and I have a project directory structure according to it:
-->src/
-->namespace1/
-->someclass.cpp
-->namespace2/
-->someclass.cpp
When I compile the application with qmake, it puts all object (.o) files to one directory - so it creates someclass.o file first and then it rewrites it with the second someclass.o - which is a name collision so it is bad.
Why does qmake not take into account the directory structure of the source files and why does it not create something like namespace1_someclass.o and namespace2_someclass.o?
Yes, I can put my classes to one directory and name them namespace1_someclass.cpp and namespace2_someclass.cpp and there will be no name collisions, but this causes little inconvenience while looking at the source files in the project explorer in Qt Creator because when there are lot of source files in the project, it is much less readable than if there was the directory structure which I can expand or collapse.
One more extreme is to have the directory structure like this:
-->src/
-->namespace1/
-->namespace1_someclass.cpp
-->namespace2/
-->namespace2_someclass.cpp
which solves name collision but it redundantly duplicates the namespace names - and therefore again less readable.
Why does qmake not have at least an option to put the object files to the directory structure according to the source files? Do creators of Qt not see that this is an important feature?
And one more thing - you could recommend me to use cmake tool instead of qmake but I see the use of cmake much much much more difficult than qmake and qmake does its job excellent for me so far - except object files placement.
You can actually put object files alongside source files by using:
CONFIG += object_parallel_to_source
or
CONFIG += object_with_source
depending on your qmake version.
Source: https://wiki.qt.io/Undocumented_QMake#Config_features
Depending on what you are trying to build, you may be able to use the subdirs template in qmake to do this. You'll need to put a project file in each of your namespace directories, and in this you can specify different output directories for your object files.
-->src/main.pro
-->namespace1/n1.pro
-->someclass.cpp
-->namespace2/n2.pro
-->someclass.cpp
main.pro:
TEMPLATE = subdirs
SUBDIRS = namespace1 namespace2
n1.pro and n2.pro:
include("../common.pri")
OBJECTS_DIR = $${PWD}
TARGET = some_target
TEMPLATE = some_qmake_template
common.pri: configurations common to both projects.
Concerning your fears that CMake might be too complicated: I have been working on projects using both build systems. While I agree that qmake is probably easier to begin with, CMake definitely has its merits, too:
It makes out-of-source builds very easy. Just execute cmake <Path to source> in your build directory. This is great when your sources are on an NFS share, for example, and you want the object files to be placed on a local file system.
Its support for finding additional libraries is very powerful. Lots of FindXXX.cmake files are already shipped with your CMake distribution, making the inclusion of "heavy" libraries such as OpenCV as easy as FIND_PACKAGE(OpenCV REQUIRED).
It even has out-of-the-box support for Qt. In fact, I use it for a larger software project where Qt is used for the GUI part. We decided on CMake because we required platform independence and multiple libraries which we could not easily add via qmake.
All in all, use the build system you are comfortable with (as long as your build system does not inhibit your software development).
I have been trying to use QCA (Link) on my Windows PC for a couple of days now, works fine on my linux box, just can't get it working with Windows.
So i followed all the instructions for installing QCA and then the ossl plugin for QCA. The QCA works fine but for some reason the plugin isn't showing up in my Qt Creator nor am I able to use some of the functions in the plugin.
I used the qcatool2.exe that comes with QCA to check my plugins using
qcatool2 plugins --debug
and get this error message:
plugin: qca-ossl2.dll: failed to load: The plugin 'C:/Qt/2010.05/qt/plugins/crypto/qca-ossl2.dll' uses incompatible Qt library. Expected build key "Windows mingw debug full-config", got "Windows mingw release full-config"
Now this seems to me as if qt requires the plugin to be compiled in debug mode (as to get the build key to contain debug rather than release) so I added
CONFIG += debug
to my plugin's project file and ran qmake and mingw32-make as usual but this seems to have had no effect.
My project file for the plugin is now:
TEMPLATE = lib
CONFIG += plugin
QT -= gui
DESTDIR = lib
VERSION = 2.0.0
unix:include(conf.pri)
windows:CONFIG += crypto
windows:include(conf_win.pri)
CONFIG += create_prl
SOURCES = qca-ossl.cpp
windows:{
load(winlocal.prf)
isEmpty(WINLOCAL_PREFIX) {
error("WINLOCAL_PREFIX not found. See http://delta.affinix.com/platform/#winlocal")
}
OPENSSL_PREFIX = $$WINLOCAL_PREFIX
DEFINES += OSSL_097
INCLUDEPATH += $$OPENSSL_PREFIX/include
LIBS += -L$$OPENSSL_PREFIX/lib
LIBS += -llibeay32 -lssleay32
LIBS += -lgdi32 -lwsock32
}
!debug_and_release|build_pass {
CONFIG(debug, debug|release) {
mac:TARGET = $$member(TARGET, 0)_debug
windows:TARGET = $$member(TARGET, 0)d
}
}
CONFIG += debug
Has anyone got any ideas? If you need anymore details just ask, I've tried to be as thorough as possible. Thanks
Tom
I've been struggling with a similar situation: qca-ossl builds fine on linux and not at all on windows. I just hit a breakthrough which might help you as well.
Versions and Patches
qtsdk-2010.05
qca-2.0.3
qca-ossl-r1190163 (from the repository)
openssl-1.0.0b
First of all, if you're using a newer version (0.9.7+, I think) of OpenSsl, you may need to use the qca-ossl version from the repository since it patches some incompatibilities. I also needed to comment out some lines in the new qca-ossl.cpp file dealing with SHA224, SHA256, SHA384, and SHA512 to avoid build errors. I'm using qca-ossl for the ciphers, so I'm not worried about hashing and didn't investigate the errors very much.
Fixing It
The windows build problems were many fold for me, but most of them stem from the shoddy build setup for the windows version of the plugin. It's nice having a little configure script for the linux side of things, but what about windows? We need to do a little extra work.
Some of this extra work is because I've chosen non-standard locations for the support libraries of my application. Qca and OpenSsl both exist within the project's directory structure in a libraries/ directory. My guess is that you've done something similar if you are trying to cross compile your application, but even if you didn't the following should help.
Finding OpenSsl
Qca-ossl wont build very well if it can't find the library it's supposed to connect to... :) So let's specify directly where it is. Comment out the lines relating to winlocal.prf and the changes that stem from it in qca-ossl.pro. We will directly specify where to find openSsl.
TEMPLATE = lib
CONFIG += plugin
QT -= gui
DESTDIR = lib
VERSION = 2.0.0
unix:include(conf.pri)
windows:CONFIG += crypto
windows:include(conf_win.pri)
CONFIG += create_prl
SOURCES = qca-ossl.cpp
windows:{
# Rather than rely on the winlocal.prf file, we will specify the location of the openssl
# by hand when running qmake.
#
# load(winlocal.prf)
# isEmpty(WINLOCAL_PREFIX) {
# error("WINLOCAL_PREFIX not found. See http://delta.affinix.com/platform/#winlocal")
# }
#
# OPENSSL_PREFIX = $$WINLOCAL_PREFIX
DEFINES += OSSL_097
INCLUDEPATH += $$OPENSSL_PREFIX/include
LIBS += -L$$OPENSSL_PREFIX/lib
LIBS += -llibeay32 -lssleay32
LIBS += -lgdi32 -lwsock32
}
!debug_and_release|build_pass {
CONFIG(debug, debug|release) {
mac:TARGET = $$member(TARGET, 0)_debug
windows:TARGET = $$member(TARGET, 0)d
}
}
Now we have direct access to the $$OPENSSL_PREFIX environment variable in the .pro file. We can set it when we call qmake by doing the following.
qmake.exe "OPENSSL_PREFIX=C:/path/to/openssl-1.0.0b"
You should be able to use backward slashes or forward slashes. Here I choose forward since Qt has deprecated them since 4.7.
Alternatively, you could set the OPENSSL_PREFIX variable directly in the .pro file.
Finding Qca
After comparing the unix and windows makefiles for qca-ossl, oddly enough, it never includes the qca libraries for building or linking! ?!?! This led to an "Undefined interface" error on the Q_INTERFACES(QCAPlugin) line of the opensslPlugin class definition at the end of qca-ossl.cpp.
To avoid this, we will need to explicitly define the include and library paths by hand. Expanding on the qmake line from the last section the final qmake line is as follows.
qmake.exe "OPENSSL_PREFIX=C:/path/to/openssl-1.0.0b" "INCLUDEPATH+=C:/path/to/qca-2.0.3/include/QtCrypto" "LIBS+=-LC:/path/to/qca-2.0.3/lib -lqca2"
"Installing" Qca-ossl
After running the qmake line above and running a plain ol' make, you'll need to install Qca-ossl. You can copy the resulting dll from the lib/ directory to your Qt's plugins directory, which if you're using my versions defaults to C:\Qt\2010.05\qt\plugins\crypto. Alternatively, you can move it to a crypto directory that's at the root level of your project's directory structure such as C:\path\to\my\project\crypto.
I hope this helps!
Actually, you can try this tutorial QCA+OpenSSL on Window. It's work well.
By the way, I can make use of QCA with AES 256 on Window. But i can't use it on Symbian. Any idea to do it?
Related Post