So, there I'm writing some library and desided to have a proper unit-testing for it (like TDD and so on). QtTest framework looked suitable to start with. The library itself is fine, so is the test.
But when I added both the library and the test project to my job project, CI build surprisingly failed. It occured that the test executable (LibraryTest.exe or similar on Linux) was being copied:
to %QTDIR%/tests in a separate folder on Windows
to /usr/tests on Linux
My test project settings added this behavior to the "install" build stage, there they are (important ones):
QT += core testlib
# The problem is below
CONFIG += c++11 qt warn_on depend_includepath #testcase
CONFIG -= app_bundle
LIBS *= -L$$PWD -lmylibrary # not exact, does not matter
TARGET = LibraryTest
SOURCES += \
tst_my_library_test.cpp
DEFINES *= QT_FORCE_ASSERTS
DESTDIR = $$PWD/bin
As you can see, after commenting out CONFIG += testcase the executable is not copied somewhere anymore. I've read that this configuration option is used for automated tests, that looks useful, but nothing is written about any special install stage. The test executable exists in the DESTDIR just fine, so it is not some accident error.
My question is: why is it happening? Can I specify some other folder?
Automation is usefull, but even if implemented it would be probably bound to some more convenient directory.
Am I cooking the QtTest wrong? Thanks in advance for your attention.
Okay, after hacking the tests in my own way and getting enough time to study the problem thoroughly it occured that Qt's tests are designed to be used in a quite another way than I've thought.
It was obvious, that the testcase's makefile differs from the regular one, but the official documentation just stated the following:
For testcase projects, qmake will insert a check target into the generated Makefile. This target will run the application. The test is considered to pass if it terminates with an exit code equal to zero.
This gave a hint, what exactly resulted in makefile having extra install_target: first FORCE with strange and wrong file copying, but didn't explain the behavior deeper.
After some more seraching I found the following here:
Note also that Qt tests have only been tested with a non-installing Qt (the -prefix $PWD option above). The test project files override the make install target, so they are not installable. And Qt doesn't work at all if it's not at its installation path.
As far as my project uses heavilly the install build step and the tests were part of the project tree, it explained the problem.
Related
I have a larger project in which some *.qrc files are used and compiled using Qt's RCC. The project is configured via CMake as a Unix Makefile project.
When I build the program via make everything works without problems, but when I build via Cmake --build the corresponding files are not compiled. Unfortunately, CMake does not produce any output describing the problem (-verbose option is set). Does anyone have an idea what this could be? Could it be path variables? If so, how can I set them for the build process? What is the best way to debug such a problem?
To add the target I'm using qt5_add_binary_resources
The platform I am using is macOS.
I had a kit set up in Qt Creator 3.0.1 that pointed to my cross toolchain. This worked until I ran into a bug in the compiler and now have to upgrade to a newer version.
I've obtained a newer toolchain. I went into Creator, edited my kit, and updated the path to the compiler and gdb binary to point to the new toolchain.
However, when I build my project, it's still calling the old toolchain's compiler.
I've even completely deleted my kit, compiler, and debugger and recreated their configuration, but no joy.
I double-checked the mkspec that is being used, and there is nothing in there with hardcoded paths to the compiler, just things like QMAKE_CXX = $${CROSS_COMPILE}g++. I don't have the CROSS_COMPILE variable set. I did try setting it (in Creator's build environment editor) but no joy there either.
How do I get Creator to use my new toolchain?
EDIT - NEW INFO
I tried running the same qmake command line Creator does when it builds (according to its build output). First, the call to qmake I'm making is returning to the command line without creating a makefile. Here is the command I'm running:
/qt5/bin/qmake /s/src/tfs/porject_dirs/Myproject.pro -r -spec devices/linux-am335x-g++ CONFIG+=declarative_debug CONFIG+=qml_debug
So, I added a -d to get some qmake debug output. I found some fishy lines that pointed to some files that are in my mkspecs directory.
What are these files that were installed when I built Qt?
qconfig.pri
qdevice.pri
qfeatures.pri
qmodules.pri
Three of the four (not qfeatures.pri) include in them hard coded paths to the compiler I used to build Qt. I suspect that these are my problem.
Why does Qt Creator allow a compiler to be specified if these files might be overriding it? Is it safe to edit these files? Do I have to rebuild Qt simply to change the compiler used to build my application?
There is, an open bug in Qt that leaves hardcoded paths in the .pri files mentioned in my question.
Update
The bug has been resolved.
I followed these instructions in the configuration of OpenCV SDK for using it in Qt Creator IDE, but I couldn't conclude point 6.5, due to configuration errors in Cmake-GUI. I setup the configuration in CMake of the compilers gcc and g++ contained in Qt folder for MinGW32, and all looks Ok. But when Cmake-GUI starts the process of build configuration it ends up saying
"Error in configuration process, project files may be invalid".
It can't find the following:
QT_QMAKE_EXECUTABLE;
Qt5Concurrent_DIR;
QT5Core_DIR;
QT5Gui_DIR;
QT5Test_DIR;
QT5Widgets_DIR.
After this issue I tried to go on with following points of configuration tutorial, without reaching the final instruction of mingw32-make install. I'm using the following versions of softwares: Qt 5.3.0, OpenCV 2.4.9, CMake 2.8.12.2. My OS is Windows 7.
How can I recover the missing Qt files in CMake configuration?
Is there an alternative way for configuring OpenCV with Qt (like using precompiled build of OpenCV libraries)?
You just need to indicate CMake the correct paths to each one. Click oh the path to browse and set each one individually:
QT_QMAKE_EXECUTABLE;
For this one, you need to search inside the Qt installation folder for the /bin directory. On it, you' ll find the qmake.exe. In my case it was C:/Qt/5.3/winrt_x64/bin/qmake.exe
All the following ones are in the Qt's /lib/cmake directory. In my case: C:/Qt/5.3/winrt_x64/lib/cmake :
Qt5Concurrent_DIR;
C:/Qt/5.3/winrt_x64/lib/cmake/Qt5Concurrent
QT5Core_DIR;
C:/Qt/5.3/winrt_x64/lib/cmake/Qt5Core
QT5Gui_DIR;
C:/Qt/5.3/winrt_x64/lib/cmake/Qt5Gui
QT5Test_DIR;
C:/Qt/5.3/winrt_x64/lib/cmake/Qt5Test
QT5Widgets_DIR.
C:/Qt/5.3/winrt_x64/lib/cmake/Qt5Widgets
Then click generate. It' ll show a new error and ask you for the QT5OpenGL_DIR. Just as before, show CMake the correct directory. In my case: C:/Qt/5.3/winrt_x64/lib/cmake/Qt5OpenGL. Finally, click Configure again, and then Generate, and now you're done creating the build files.
You have to specify the location of Qt manually by passing it as an argument for QT5Core_DIR. Qt5_DIR or CMAKE_PREFIX_PATH does also the trick.
Example
Given your Qt 5 is installed at /opt/selfcompiled/Qt5. When calling cmake, add the flag from above:
cmake -DQt5_DIR=/opt/selfcompiled/Qt5 <pathToSourceDir>
Once the Qt 5 directory is set and found by CMake, all the other variables related to Qt 5 should be found from there, too.
I am trying to compile QT for ARM.
But the linker requires "--sysroot" option to be added for linking files.
So in qmake.conf file, we added under QMAKE_LFLAGS.
But when we compile, its adding this even for initial tools build on the x86 PC. So gcc complains and gives error.
The cross compiler tool chain which doesnt have a .pc file.
Please let me know where to add the "--sysroot" so that this is added only when it tries to cross compile.
Thanks.
Hari
You can do this using qmake scopes - specifically platform scope variables. To ensure that -sysroot is only evaluated for your ARM builds you can do something like this:
arm-linux: {
QMAKE_LFLAGS += --sysroot
}
You may need to change the scope, depending on the platform you're actually targetting.
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.