We would like to use scons for building on Windows, mainly because of its caching facilities (we use ccache on Linux, and compiliation is considerably faster there). However, all our projects are defined in qmake .pro files. The way building now works, is that we call qmake to generate a Makefile, which we then use to build with jom. Having .pro files on a high level is quite practical, so we would like to keep that and not replace the .pro files by SConfigure files. So ideally we would have qmake generate a SConfigure file, the same way it generates a Makefile now, and then run scons on that SConfigure file. Is there something out there that can do that, maybe some generator for qmake? Or is it somehow possible to convert the Makefile created by qmake into an SConfigure file?
(I'm aware that the functionality of scons and qmake overlap, for instance the dependency generation and that it would likely be better to use just scons by itself, however, qmake works quite well for Qt projects and can also generate visual studio files, so we would like to keep it.)
They are not very happy with meta meta makes. However, as suggested in that rejected merge request, something might be possible off-source using QMAKE_SUBSTITUTES, but that is a practically undocumented feature.
Or you could go the way I tried and tinker with the code directly. Have a look at https://qt.gitorious.org/~phresnel/qt/add-some-qmake-to-autotools-glue , or more specifically the diff at https://qt.gitorious.org/qt/qt/merge_requests/1040 . The file qmake/generators/special/filelist.cpp does most of the work.
Imho, it is really a pity that extension of qmake is not easier; the greater flexibility of CMake was also the reason why I switched to it, completely abandoning my use of qmake.
Related
So, I'm making a program with a shaders.qrc. I'm using only Qt and Cmake. I know that I can do Resources += shaders.qrc in qmake but I don't know how to do the equivalent in cmake.
I don't know where to start.
In cmake, you list all kinds of source files used to build the program in add_executable or add_library, and it figures the rest by itself. You'd put the shaders.qrc in the same place you put the rest of the source files - i.e. within add_executable.
See here for an introduction. You definitely need the set(CMAKE_AUTORCC ON) line, so that cmake knows to take care of .qrc files as otherwise it'd just ignore them.
I just want to use qmake as pro-files parser for extracting project variables (like SOURCES), nothing more. I don't need to generate makefiles.
In other similar tools "dry run" mode usually presents. I.e. "just taste this thing, but do nothing with it".
Unfortunately qmake don't have such mode, but can i emulate it with some, probably ugly||hacky way?
Now i'm trying to remove all "generation"-code from qmake source, but it is hard and long task. And i'm like simple decisions :)
The simplest way is to give the -E option to qmake. It will dump the contents of the project variables and continue without generating the makefile.
It is equivalent to the code snippet given in previous edition of this post, but dumps all of the variables and requires no changes to qmake :)
I wonder, how do people maintain CMake projects on Qt creator? When you open the project you run CMake generator and after that you can't change much. In order to add another class to the project you have to create class files by hand, add them to CMakeLists.txt and rerun CMake again. Moreover, changing the class name is a nightmare.
I do actually like CMake (except its syntax), since it has some nice features. However, maintaining a project is a nightmare. Am I missing or doing something wrong?
No, you did not, that is how cmake works: You maintain the build system by hand and generate files for your preferred build system.
That approach makes it pretty easy to support several IDEs/buildsystems using cmake. Unfortunately it also makes it impossible to have an Integrated Development Environment for cmake projects. The rather complex syntax which makes it basically impossible for a machine to modify cmake projects does not help there either.
I'm trying to deploy an application using macdeployqt. All Qt frameworks get copied correctly into the application bundle. The problem I encounter is that macdeployqt does not have write permissions on the copied frameworks which originally reside in /usr/local/lib. This is because I have installed qt using homebrew which seems to make install everything read only. My question is whether there is a better way to fix this issue then manually changing all permissions of the qt libraries inside /usr/local/lib so that I can use macdeployqt from within a qt .pro project. (I don't want to use macdeployqt manually with sudo or such)
The reason why I'm asking is because I am using many third party libraries in the project (they get copied ok etc.) which I need to update often through homebrew and thus have to redo the permission changing on them.
Thanks in advance!
Just in case someone finds this old post looking for info about macdeployqt:
Use a script to do macdeployqt in preference to scripting the macdeployqt commands in your .pro file. That will allow you to change the permissions on the files on the fly.
Here is [a snippet of] the script I use for one of my apps:
https://bugreports.qt-project.org/browse/QTBUG-23268
If you're on Windows and don't have bash, you can use perl or python. The script referenced above modifies the files on the fly to work around a bug - you can put anything you want here, including changing the permissions on the files.
Using a script also means that you have the flexibility to add commands later to do code-signing, packaging or whatever else you need.
The Qt .pro "scripting language" actually generates Makefile commands under the hood and can be quite obscure if you want to accomplish deployment tasks that relate to paths and sets of files.
Also you'll need to create an extra target or include it into your build target - either way the build process becomes more complex and more error prone.
Disclaimer: I worked on Qt for 8 years as a Senior Engineer for Nokia/Trolltech, and also have published a commercial cross-platform app using Qt.
I have a large software project which uses aspects of OpenGL for visualisation. I want to add a GUI and was thinking of using QT. Now from what I understand, building QT stuff can get ugly unless one sticks to using the qmake command...
However, my project relies on the GNU tools for building (g++, autoconf, automake, etc., etc.). Must I therefore restructure my whole build process to use qmake just so that I can use a few small aspects of QT? I am very reluctant to do so given the size of the project.
As a thought, could I possibly (somehow) use qmake for the graphical components (i.e. qt-dependent stuff) only and continue to use my standard GNU build process (make, g++ etc.) for everything else?
Thanks,
Ben.
A quick Google search turned up AutoTroll and a howto.
Personally, I have used Qt without qmake before, but it was for a personal project, so I just used a (non-portable) Makefile. I set a variable (QT4DIR, since QTDIR was used by Qt3) to point to where I installed Qt, then added -L$(QT4DIR)/lib -lQtCore -lQtGui, etc. to LDFLAGS and -I$(QT4DIR)/include/QtCore, -I$(QT4DIR)/include/QtGui, etc. to CXXFLAGS. It looks like those links explain how to do something similar for autotools.
Edit:
To handle the MOC, I've added implicit rules like:
moc_%.cc: %.h
$(MOC) $< -o $#
And then make sure that all required moc_*.cc files are included in my SOURCES. It's a bit of a pain to specify QObject-derived classes twice, but everything will get built.
After much head-scratching, I decided to compile the original code into a library using my original build process (but slightly modified to compile a library rather than a binary) and then compile the gui separately using qmake. This would then also link the gui in with the original library code. Not 100% ideal but works fine. Probably the biggest hurdle was converting some glut code into a QGLWidget...